Knowledge Center > ISACA Now

 ‭(Hidden)‬ Admin Links


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

Cybersecurity Month is here—and so is ISACA’s new cybersecurity certificate

Cybersecurity MonthOctober is Cybersecurity Month, and ISACA is proud to be a champion of two of these initiatives:

Cybersecurity Month—along with the latest breach headlines dominating the news—reminds us how critical it is for our enterprises and individuals to be at the top of their games when it comes to security. We all have important roles to play, regardless of whether the word “security” is in our job titles. For some ideas on how to get involved this month, view this video.

National Cyber Security Awareness MonthMany exciting things are happening at ISACA during Cybersecurity Month. For instance, last Monday marked the launch of the new Cybersecurity Fundamentals Certificate. Intended for university students and recent graduates, entry-level security professionals, and those seeking a career change, the certificate is knowledge-based and requires passing a proctored online exam.

Category: Security     Published: 10/13/2014 11:43:00 AM

Designing a quality management approach to cybersecurity

Mark E.S. BernardDesigning a quality management approach to cybersecurity starts with two sets of security standards, (1) the manufacturer and (2) the organization.

The manufacturer standards should include the mitigation of security vulnerabilities, (OWASP, CVE), based on a specific configuration within a defined architecture. There are only so many situations in which a network device firewall, router, switch, server, desktop, laptop, handheld can be deployed. The software, enterprise resource planning (ERP), utilities, apps, etc., should also be tested for security vulnerabilities before they are released.

We need to weed out the technologists who insist on flying by the seat of their pants. They can expose the organization to unnecessary reputational risks and potential financial and strategic risks. By not documenting security standards, the organization will be not be able to produce consistent outputs. It is impossible to manage quality when nothing is documented; it cannot be validated or verified.

The organization's security standards need to define how a network device will be implemented. This usually means that only a select list of manufacturers and products that have been tested and meet the organization’s requirements can be purchased. This also means that the security architecture needs to be documented based on those specifications and business requirements. These specifications need to be meaningful, because they will be tested, verified and validated.

Category: Security     Published: 10/9/2014 3:10:00 PM
<< First   < Previous     Page: 1 of 85     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.