You Can’t Patch People

December 29, 2012 at 5:06 pm | Posted in Data Protection, Endpoint Security, Human Factors in Security | Leave a comment
Tags: , , , ,

In a recent blog post, Bruce Schneier highlighted how a commercially available and low-cost  (around £200) forensics tool is capable of cracking passwords for common commercial whole disk encryption products.

As I mentioned in a previous post, use of PGP Desktop to encrypt all laptop disks  is compulsory at IBM and is enforced through our end-user computing standards.

The default power management configuration for laptops often just suspends the laptop when the lid is closed or when ‘sleep’ button is pressed. unless the laptop user selects ‘hibernate’ the disk drives are not encrypted. standards dictate that laptop configuration should be changed to hibernate in these circumstances, but how many users actually make the necessary changes?

The comprehensive help documents provided by IBM for configuring the whole disk encryption software step the user through making a ‘rescue disk’ to allow recovery in the event of a lost encryption password. So, how many users take any precautions to protect that?

Going back to the potential attack against whole disk encryption, it relies on the attacker being able to recover the encryption key from memory dumps or hibernation files, after the disk has been decrypted. Of course, if the laptop is always left safe (ie. powered down or at least hibernating) then that attack vector isn’t available. However, how many users leave their laptop unattended and logged in when they believe the environment is ‘safe’? And, how many leave their laptop unattended before the hibernation process has completed?

The common thread through all of this is that if users are careless, they can inadvertently cancel out any benefits from technical countermeasures. It’s simple enough to describe the exact behaviour that will prevent this. In Public sector security, we call this Security Operating Procedures, or SyOPs for short.

It’s usual to define the IT security risk management process as starting with risk assessment to select the right security controls, followed by incident management to deal with residual risk, invoking crisis management and BCP when required, to recover from the most severe incidents. I strongly believe that SyOP production and security awareness training for end users must form part of the risk management process and must be in place before a service is activated to ensure that the security controls operate as designed and to defend against the sort of attack described here.

As I said in the title, users are the one part of the system that can’t be patched to remove vulnerabilities.  It’s vitally important to explain the importance of what we ask them to do and then to reinforce that through adherence to mandatory written instructions, in order to establish the ‘habit’.

Advertisements

Out of the Loop

November 14, 2010 at 12:37 am | Posted in Cloud Security, Security Governance | 1 Comment
Tags: , , ,

Recently, I was reading the Times on the early train to London, and I came across a multi-page section on Cloud Security – proof positive that cloud services are now firmly on the business agenda.  While I understand the attraction of cloud in delivering quick, cost effective and scalable solutions to business problems, it strikes me that it also presents yet another opportunity for the business to cut IT (and particularly IT Security) out of the decision making process.

A few weeks back the BCS Information Systems Security Group held their AGM at IBM Bedfont and a number of IBMers including myself presented during the course of the day.  My topic was “Maintaining Security Governance in the Cloud”.

My central theme was that cloud computing offers the prospect of delivering IT capacity that dynamically flexes to meet changing business requirements.However, this flexibility and cost-effectiveness comes at a price.There is a substantial risk that sensitive information will leak out of the business, and the lack of transparency of the provider’s security processes make it essential that the business’s security governance processes are adapted to reflect these new risks.

Burton Group (recently acquired by Gartner, Inc.), Cloud Computing Security in the Enterprise, Dan Blum, July 15, 2009

So, faced with a new set of risks and preparing to trade control over IT systems (and their security) for the benefits of the SPI model of cloud services, never has it been so vital for the business to take good advice from  security Subject Matter Experts on the increased governance processes needed to protect the business data and (more importantly) its reputation.   Studies and surveys regularly report that 75% or more of businesses view security as the biggest single inhibitor to moving their IT operations into the Cloud.  This suggests that those businesses understand – at least intuitively – that traditional controls are built on physical access to the technology stack and that Cloud deployment models mean that control is passed to the Cloud Provider.  Nevertheless, a recent study conducted by Ponemon Institute for Symantec (“Flying Blind in the Cloud.  The State of Information Governance“) suggests that businesses are prepared to enter into contracts with Cloud Service Providers, without engaging their IT security team to advise them:

  • 65% select a CSP based on market reputation (word of mouth) while only 18% utilise their in-house security team to carry out an assessment
  • 80% admit that their in-house security team is rarely or never involved in the selection of s CSP
  • 49% are not confident that their organisation knows all the cloud services that are deployed.

In fact, businesses need to enlist the specialist knowledge of their security SMEs to help with the selection of a CSP and the negotiation of contracts.  The Cloud Security Alliance suggests in “Security Guidance for Critical Areas of Focus in  Cloud Computing V2.1” that,  together, they need to:

  • Review specific information security governance structure and processes, as well as specific security controls, as part of due diligence when selecting cloud service providers
  • Incorporate collaborative governance structures and processes between the business and the provider into service agreements
  • Engage their Security SMEs when discussing SLAs and contractual obligations, to ensure that security requirements are contractually enforceable.
  • Understand how current security metrics will change when moving to the cloud.
  • Include security metrics and standards (particularly legal and compliance requirements) in any Service Level Agreements and contracts.

Security SMEs will help to bring this about, when we can present a clear and unambiguous explanation to the business as to how the balance of risks and controls is altered in e Public Cloud and how this needs to translate to more sophisticated shared governance.  this in turns requires that we have a precise definition of what Cloud is and a robust baseline of cloud security knowledge.  The Cloud Security Alliance has introduced the Certificate of Cloud Security Knowledge (CCSK) to address this latter issue.  This certification is not designed to replace existing well-established schemes, such as CISSP, CISM and CISA, but rather  to demonstrate competence in the specific security challenges of Cloud deployments, by testing an understanding of two significant and authoritative documents:

The CCSK is strongly supported by a broad coalition of experts and organizations from around the world. The collaboration with ENISA means that the world’s two leading organizations for vendor neutral cloud security research are providing the foundation for the industry’s first cloud security certification. CSA’s breadth of industry participation and strategic alliances are being leveraged to communicate the need and value of this certification to employers within cloud providers, cloud consumers, consultants and variety of other stakeholders.  I’ll nail my colours to the mast here and commit to sitting the CCSK exam before the end of this year.  How about you?

An Offer too Good to Refuse

August 18, 2009 at 2:41 pm | Posted in Programme Management, Uncategorized | 3 Comments
Tags: , ,
Thinking String - Unravelling Complexity

Thinking String - Unravelling Complexity

I was delighted (and more than a little anxious) to be asked recently by Simon Perry to contribute to his Thinking String website. As you may know, Simon has established Thinking String as a federated consultancy, providing expert and hype-free guidance to technology vendors, service providers and academia which are developing solutions that enable an effective and equitable low carbon economy.

I’ve had the pleasure of working with Simon for a number of years, when we were both part of CA’s EMEA Security team.  More recently, Simon was ranked the 2nd most influential analyst on Green IT and Sustainability in the Analyst of the Year annual survey, conducted by the Institute of Industry Analyst Relations (IIAR).

I’ll be writing for Simon from time to time on matters concerning risk and programme management, as well as my own subject area of Identity and Access management.

 Destined to Fail?

My first article for Thinking String  addresses the problems that seem to surround delivering large scale infrastructure projects and programmes successfully.  By large-scale infrastructure projects, I’m thinking of those projects, which span all (or most) Business Units and locations and impact upon multiple business processes.   Admittedly, my observations are drawn mostly from enterprise security management deployments (in particular Identity and Access Management), although I suspect that the same is true of other technology management areas, such as Network and Systems Management and Service Management.  You can read the whole article on the Thinking String website, but I’ll include the key points here:

  • Make a plan – and stick to it!  Once the design is signed off, resist the temptation to adopt a new version or service pack, unless there’s a very clear need for some functionality to overcome a major problem.
  • Listen to the vendor. They know what they’re talking about (most of the time).  Consider the use cases that need to be satisfied during the selection phase and select a vendor that closely aligns with those. During deployment, the closer you can then stay to the chosen vendor’s logical architecture, then the more likely it is that the deployment will be successful.
  • Beware Showstoppers.  Be sure that the governance arrangements for your project are adequate to ensure that the impact to your project will be considered by the decision makers and also that you have a channel to “escalate” if a project assumption should prove false.
  • Deliver frequently in small increments and prioritise by value returned.  Deliver key use cases first and make regular deliveries of additional functionality, to ensure that the Business can see the value of continuing.

Infrastructure projects can and of course do succeed in delivering value to the Business.  But, to achieve this, you need to put a lot of effort into programme management and in particular into publicising your project and its successes to the Business.  Above all, keep in mind that just because it’s infrastructure, doesn’t mean that it’s all about IT.  Remember that people and processes are involved too.

Create a free website or blog at WordPress.com.
Entries and comments feeds.