Knowledge Center > ISACA Now

 ‭(Hidden)‬ Admin Links


NIST Privacy Workshop Moves Forward with Framework Development

Rebecca HeroldI attended the second National Institute of Standards and Technology (NIST) Privacy Engineering Workshop on behalf of ISACA, which was held in September in San Jose, California, USA. NIST took the information that they collected at their first workshop in April 2014 and put together a proposed high-level draft of the beginning of what will eventually become the privacy engineering framework—the “Preliminary Concepts” that will ultimately become integrated with the U.S. Framework for Improving Critical Infrastructure Cybersecurity, which was published early this year.

This workshop focused on four primary activities:

  1. Reviewing the proposed privacy engineering definitions
  2. Reviewing the proposed “System Privacy Risk Equation”
  3. Determining a lexicon of privacy objectives, establishing common terms and categorizing potential privacy harms
  4. Hearing from engineers, privacy experts and privacy advocates about additional issues

Proposed Privacy Engineering Lexicon
If engineers are expected to be able to understand privacy principles and then build privacy controls into their systems, devices and processes to effectively protect privacy, then they must be operating under a common vocabulary to understand the terms in the same way across the enterprise and then consistently implement the privacy controls. Some of the terms proposed by NIST, based upon their research and feedback from the April workshop, include three primary privacy engineering objectives and some primary privacy terms that all engineers need to know and understand.

Category: Privacy     Published: 10/23/2014 3:24:00 PM

Meeting the PCI DSS Compliance Guidelines

Adesanya AhmedCloud computing has the ability to offer organizations long-term IT savings, reductions in infrastructural costs and pay-for-service models. By moving IT services to the cloud, organizations are more geographically distributed than ever before and the pace of business gets faster every day. Online collaboration has become a business necessity—there is no other way for distributed teams to work as quickly and efficiently as business demands. With virtual, paperless environments becoming more common, simply locking the doors at night no longer protects merchants, banks, customers or the business they conduct.

This means that exploitation will change from systems to web. Due to these changes, today’s business needs demand that applications and data not only move across physical and international borders, but also to the cloud and accessible by third parties. This loss of control is significant for security teams that must not only keep data safe, but also comply with the necessary security standards, including the Payment Card Industry Data Security Standard (PCI DSS). The payment card industry (PCI) should recognize that the most effective way to protect customer data is to protect the networks from the point of purchase to the application servers in their networks.

The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices and applications.

Category: Cloud Computing     Published: 10/22/2014 3:08:00 PM

Why is it so hard to explain cybersecurity?

Steve SchlarmanAs someone who has been in the cybersecurity industry for many years, I have witnessed more confused, perplexed, dazed and otherwise confounded looks than I care to admit. Nearly all of them asked simple questions like “What do you do at your job?” or “How do you actually secure XYZ?” Recently, I have been hearing a lot of questions about security breaches including; “Why do I keep reading about these security breaches in the news?” When I start to explain the answer, the listeners quickly become disengaged and one of the looks I mentioned earlier soon appears on their faces. Cybersecurity should not be hard to explain but so often it is. As security practitioners, we are always ready for the analogy–pick your favorite–the castle, the bank vault, the battlefield, etc.–but it always seems to fall short of actually educating the audience.

Some questions are more prevalent than others these days and in your company I am sure you get some stream of questions from your business partners and colleagues. First is “Why is it so hard to keep the bad guys out?” This is a completely relevant and fair question but is not easy to describe in simple terms without pulling out at least some technical jargon. Another favorite is “How do these data breaches happen?” Again–without technical explanations–you are most likely faced with explaining how people break into a home or business physically. It might make the point but the person is no more educated on technological security challenges than when the conversation started. Next, questions are asked like “What is a vulnerability and why can we not fix them?” and “How did the security team not see what was happening?” At this point, the conversation is really going downhill fast if you are trying to avoid a confused questioner. Ultimately, the discussion arrives at the basic question “How can companies get better at cybersecurity?” At this point, explanations of defense in depth, event and packet analysis, and other components of a well-designed and effective security program, frequently leave the questioner confused and frustrated.

Category: Security     Published: 10/21/2014 3:08:00 PM

The future of GRC technology: reporting from the customer perspective

GRC coverEarlier this year, OCEG released its global 2014 GRC Technology Strategy Survey report and it reveals some expected and some unexpected findings.

More than half of the 273 participants indicate that their organizations are currently underutilizing technology that they have acquired to manage governance, risk and compliance (GRC) needs. Not surprising, really, since they also indicate that more than 80% of GRC solutions being used are department or issue-focused stand-alone solutions that are not integrated with other GRC technology solutions. In fact, 57% report that what they actually are using to manage GRC information is a heavy dependence on spreadsheets.

As a result, 70% report that their currently deployed approach and technology are not aligned to the GRC needs of the organization. They see it and they know it is a problem. And finally, after a half dozen years of largely limited budgets, there appears to be a move toward investing in change. Nearly two-thirds say that they are aligned to take action on future enterprise GRC technology initiatives, and roughly 80% indicate that they are making decisions on an enterprise-wide or multi-department basis.

It’s interesting to see that, unlike the answers in earlier OCEG surveys, the focus seems to be on spending for new technology. In the past, efforts were more often aimed at seeking ways to reuse or revamp existing systems for additional uses. 41% of the survey participants indicate that they plan to buy new GRC technology this year, and another 58% say they plan to make purchases in the next one to two years.

Category: Risk Management     Published: 10/16/2014 3:21:00 PM

Can you trust your cloud provider?

Antonio RamosIt is a fact that our organizations’ ability to deliver a service is increasingly dependent on third-party service providers. When it comes to IT service provision, there is no difference.

Facing this scenario, with growing pressures pushing us to reduce costs and embrace this new delivery model of cloud computing, there is an obvious question that will come to mind: Can I trust my cloud provider?

Trust is a very complex issue, and it is not easy to define all the conditions needed to gain it—but transparency is definitely a necessary condition. Being able to know, even before use, the security measures that are effectively implemented in an ICT service is quite useful for assuring the right security levels in the supply chain. This is especially true thinking about using a cloud computing service. Traditionally, following due diligence best practices, we try to audit the service providers or get an independent audit report or certification from them, but we have faced some difficulties:

  • Auditing is not easy, and it is even more difficult if there is not yet a signed agreement with the provider.
  • If we use audit reports from the providers, we have to check if what has been audited is relevant for us—specifically for the service we are going to use—or if the criteria fit our needs.
  • Cloud providers, especially the bigger ones (that have hundreds or even thousands of customers), cannot afford being audited by each customer.
  • If a certification is presented to us, we have to check again if the scope is suitable for us. Additionally, we have to be aware that current certifications are not about the implementation of security measures; they are about the implementation of information security management systems.
  • Finally, all these methods tell us something about a moment in time, but they do not keep this information updated; we have to wait until the next audit/certification report.

If we had a way to compare different services and make sure that security measures were taken throughout the service period, it would be very helpful for our service provider selection process. As I discussed in my presentation at ISACA’s EuroCACS conference, security labeling of ICT services is a way to achieve all these objectives. This method assigns a label to every specific user showing the security measures it effectively implements in that service, allowing us to know in a quick and simple way if it is suitable for our needs. This recommendation to the industry was included in the European Cyber Security Strategy approved in February 2013, so it is something that the European Administrations will be willing to use.

Category: Cloud Contracts     Published: 10/14/2014 3:07:00 PM
<< First   < Previous     Page: 1 of 86     Next >   Last >>

 About This Blog


This blog is intended to offer a way for ISACA leaders, constituents and staff to exchange information of interest pertinent to the association, the business environment and/or the profession.

The comments on this site are the author’s own and do not necessarily represent ISACA’s opinions or plans. ISACA does not endorse, monitor or control any links to external sites offered in this blog, and makes no warranty or statement regarding the content on those external sites.

Anyone posting comments on this site should ensure that the content remains on-topic and steers well clear of any statements that could be considered insensitive, offensive or threatening. Given ISACA’s global nature, the need to communicate in a way that is accessible and acceptable to many cultures should be taken into account. ISACA retains the right, at its sole discretion, to refuse content that is considered inappropriate.


To volunteer to write a blog or suggest a topic send an email here.