Black Box versus White Box testing and when to use them

I have recently been speaking to many security professionals and asking them about black box and white box testing. I have used it as an interview question on many occasions as well. People's answers are varied and interesting, but I thought I would share my views briefly here.

Firstly, what are black box testing and white box testing, or grey box testing for that matter? Simply put, a black box test is one where the tester has no knowledge of the internal structure or workings of the system and will usually test with security protections in place. They may not even be given credentials to a system that requires authentication. This would be equivalent to what a hacker would have access to.

The opposite extreme is a white box test, where the tester has full knowledge of the system and access to the code, system settings and credentials for every role, including the administrator. The tester will likely be testing from inside the security perimeter. Grey box testing sits somewhere in the middle, where the tester will have knowledge of the functionality of the system and the overall components, but not detailed knowledge. They will usually have credentials, but may still test with some security controls in place.

So, when would you use the different levels of testing? Personally, I think that grey box testing is neither one thing nor the other and holds little value. For me, the motivation behind black box testing is compliance, whereas the motivation behind white box testing is security. With a white box test you are far more likely to find security issues, understand them and be able to fix or mitigate them effectively, so why wouldn't you do it? The black box test is supposedly what a hacker would see, but they have far more time, so it isn't even representative. The only reason to perform a black box test is to pass some audit that you are afraid you might fail if you perform a full white box test, in my opinion.

If you actually want to be secure, then make sure you always commission white box tests from your security testers.

Improving Usability AND Security - it is possible?

I believe so, but only if security teams start to listen to what's important to the usability experts and adapt the security provision accordingly. As many have said before, there is no such thing as 100% security and we don't even necessarily want governmental levels of security for everything. Security provision should be appropriate to the systems and the information it protects.

I have worked on several projects with user experience designers and it has really changed my approach to securing systems. One particular project I was brought in to work on was having problems because the UX team were refusing to put in additional security measures and the security team were refusing to let them go live. To cut a long story short, it turns out that there are known drop-out rates for registrations or user journeys based on the number of fields people have to fill in and how many clicks they have to do. So, the requirements from the security team meant that the drop-out rates would be so high the service wasn't going to work. How can you deliver a secure service in this instance? Well we split the registration journey and allowed the first transaction with lighter weight security information. This won't work in all cases, but the idea is the same - what security is appropriate for this system?

The key here is to understand the user journey. Once you understand this, you can categorise the individual journeys and the information used. Not all journeys will access the same level of information and not all information has the same sensitivity. Authentication should be appropriate to the journey and information. Don't make the user enter loads of authentication information all the time or to do the most simple task. Some user journeys won't actually need authentication at all. For those that do, you should consider step-up authentication - that is simple authentication to begin with, but as the user starts to access more sensitive information or make changes/transactions that are high risk, ask them for additional credentials. For example, a simple username and password could be used for the majority of user journeys, but perhaps a one-time token for more high-risk journeys.

It is possible to have both usability and security. In order for this to work though, you have to:

• understand the user journeys
• ensure that it is usable most of the time for most tasks
• categorise the information and set appropriate access levels
• use step-up authentication for high-risk tasks rather than make the whole service hard to use
• use risk engines transparently in the background to force step-up authentication or decline transactions/tasks when risk is above the acceptable threshold

Internal cyber attacks - more thoughts

I presented on a panel today at the European Information Security Summit 2015, entitled 'Should you launch an internal cyber attack?' We only had 45 minutes and I thought I'd share some of my thoughts, and what I didn't get to say, here.

Firstly, as we all know, the concept of a network perimeter is outdated and there is a real blurring of whether devices should be considered internal or external these days. It's not just about BYOD, but most organisations provide laptops for their employees. These laptops get connected at home, airports, hotels, etc. Any number of things could have happened to them during that time, so when they are reconnected to the network, they may have been compromised. For this reason, it should be every system for itself, to a certain extent, in the network, i.e. assume that the internal machines are compromised and try to provide reasonable levels of security anyway.

Secondly, the user is the weakest link. It has been said many times that we spend our time (and budget) on protecting the first 2000 miles and forget about the last 2 feet. This is less and less true these days, as security departments are waking up to the fact that education of the users is critical to the security of the information assets. However, the fact still remains that users make mistakes and can compromise the best security.

So, should we launch internal cyber attacks against ourselves? Yes, in my opinion - for several reasons.

Internal testing is about audit and improvements. If we launch an internal Pentest or Phishing attack, we can see the effectiveness of our controls, policies and user education. The critical point is to not use the results as an excuse to punish or name and shame - this is not Big Brother looking to punish you. If a user does click on a link in a Phishing email then we should see it as our failure to educate properly. If a user bypasses our controls then our controls haven't been explained properly or they are not appropriate (at least there may be a better way).

An example was discussed on the panel about people emailing a presentation to their home email account to work on it from home. In the example, this was a breach of policy and, if the categorisation of the presentation is confidential or secret, then they shouldn't be doing this. However, rather than punish the user immediately, try asking why they felt that they needed to email it to their home computer. Was it that they don't have a laptop? Or their laptop isn't capable enough? Or that they think they are doing a good thing by emailing it so that they don't have to take their corporate laptop out of the office as they know they're going to the pub for a couple of hours and are worried about it getting stolen? There are motivations and context to people's decisions. We see, and usually focus on, the effects without stopping to ask why did they do it? Most people are rational and have reasons for acting as they do. We need to get to the heart of those reasons.

Education is critical to any security system and as security professionals we need to learn to communicate better. Traditionally (and stereotypically) security people are not good at communicating in a clear, non-technical, non-jargon-filled way. This has to change if we want people to act in a secure way. We have to be able to explain it to them. In my opinion, you have to make the risks and downsides real to the user in order to make them understand why it is that we're asking them to do or not do something. If you just give someone a directive or order that they don't understand then they will be antagonistic and won't follow it when it is needed, because they don't see the point and it's a hassle. If they understand the reasoning then they are likely to be more sympathetic. Nothing does this better than demonstrating what could happen. Hence the internal attacks.

The next question we have to ask ourselves is what constitutes the internal part of an internal attack. Is it just our systems, or does it include all those third party systems that touch our data? I could quite happily write a whole blog post on outsourcing to third parties and the risks, so I won't delve into it here.

I do also have to say that it worries me that we seem to be educating our users into clicking on certain types of unsolicited emails that could easily be Phishing attacks. An example that I used was the satisfaction or staff survey that most companies perform these days. These often come from external email addresses and have obscured links. To my mind we should be telling our users to never click on any of these links and report them to IT security. Why shouldn't they ask our advice on an email they're unsure about? We're the experts.

One final point was suggested by a speaker, which I think is a good idea. If we educate users about the security of their family and assist them with personal security incidents and attacks as if they are those of our company, then we are likely to win strong advocates.

Pentests Don't Make You Secure

I was asked to provide details of the 'Penetration Testing Phase' for a particular project by someone who was putting together a Test Approach Document today. The categories I was asked to fill in were:

• Objective of the phase
• Responsibility & Authority
• Dependencies, risks & assumptions
• Entry & Exit criteria

When discussing what they really wanted it became clear that they didn't know what a penetration test was or why we do them. The questions and document were set up expecting a deliverable from the pentest itself. The report was being treated as the deliverable without any thought of why a report was being produced or how it will be used. It was a tick in the box - "We require a pentest to be able to go live, so if we've had the report we can tick that box and move on."

Pentesting is not an end in itself. Pentesting is a standard, finite snapshot of the security of a system, which, if taken in isolation as a goal, is fairly useless. Pentests don't make you secure. Performing a pentest and having a report with lots of pretty colours and charts saying that high and critical vulnerabilities exist is only any good if you then remediate or mitigate those vulnerabilities. You could pentest your system every month, but if you never change anything in the system, every report will be the same and you will be as much at risk as you were before you had the pentest done. Indeed, you are likely to get progressively worse results as new vulnerabilities are discovered all the time.

The test and report themselves don't do anything for security. A pentest is used by security professionals to inform and shape a project and decisions. The actions taken based on the findings from a pentest are what improve your security and help you identify the best use of finite resources or, at the very least, enable you to understand the risk. Do you need to perform a pentest? Absolutely you do in order to understand the threat landscape properly and identify vulnerabilities, but it's what you then do with that knowledge that is important and will make you more secure (or not).

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here.

Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts.

But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform to many of my recommendations, but I have yet to find one that, by default, conforms to them all.

Site Categorisation

There are several different categories of hosting and several different ways to categorise sites, with different requirements. However, in my opinion, sites should be categorised based on the information that they contain and the level of interaction allowed. Sites should then be logically and physically separated into their categories.

Sites can be categorised as brochure sites if they have static content or do not collect information. These sites can then further be categorised into public or private depending on whether the data that they contain is public or not. Sites within these categories may be co-hosted with other sites in the same category, but the two categories should be segregated.

Sites can be classed as data collection apps if they collect sensitive or personally identifiable information (PII) from the user. Sites within this category should be hosted on their own servers with no co-hosting and be segregated from all other sites. The data must be stored on separate segregated database servers that are secured and firewalled off.

Finally, any site with even more sensitive data on it or company secrets should be hosted internally if you have the expertise in house.

Hosted Environment

The following list is an example of the requirements for secure web hosting. It is not necessarily complete, but if you do not have the following then you may have issues in the future. All websites and web applications must:

• be hosted on a dedicated environment - the hosting machine may be virtual or physical, but must not be shared with any 3rd parties. Multiple websites and applications from the same company may be hosted on the same machines according to the categories above
• have DDoS protection in place
• have AV running and configured properly on the server along with appropriate responses and reporting
• be hosted behind a Web Application Firewall (WAF) to protect against common attacks, plus allow the ability to configure it for specific services
• be hosted on security hardened Operating Systems (OS) and services to an agreed build standard
• be subject to regular and timely patching of the OS and services
• be subject to regular security testing and patching of any Content Management System (CMS) in a timely manner if used
• be subject to active monitoring and logging by the provider for security breaches and reporting to/from the organisation
• have formal incident management processes for both identifying and responding to incidents
• not be co-hosted with additional public services beyond HTTP/HTTPS (e.g. no public FTP)
• not allow DNS Zone Transfers
• use proper public verified SSL certificates - with a preference for Extended Validation (EV) certificates
• ensure that management services and ports are on different IP addresses and domain names preferably, but must not be available through the normal login or visible on the website
• ensure that administrative interfaces and services are restricted to certain IP addresses at least, but make use of client-side certificates or two factor authentication (2FA) if possible
• ensure staging servers are available for test and development, which must not be shared with live sites and should be securely wiped at the end of testing as soon as the site is deployed live
• ensure staging and test environments are not available on the public Internet or, if there is no alternative, they must be devoid of branding and sensitive information in all ways and restricted as above
• be built on a tiered architecture, or at least the database (DB) server must not sit on the same server as the web front end, must not be accessible from the Internet and must be securely segregated from the front end
• use encrypted storage for all sensitive information, (e.g. passwords and sensitive information)

Hosting Services

It is up to the hosting provider and third party developers, but should be backed up by specific contractual clauses, to ensure that:

• the site is backed up regularly off site in a secure location using encrypted media where the keys are stored separately from the media and able to be restored in a reasonable time frame with a suitable rotation and retention policy
• hardware and media that has reached the end of its life is securely destroyed
• all sites are made available for pentesting prior to going live and at regular intervals
• all vulnerabilities considered of medium risk and above should be remediated prior to go-live
• all sites are available for on-going regular automated Vulnerability Assessments
• domain names, code and SSL certificates are registered to the company and not a third party
• there are agreed processes for identifying approved personnel to authorise changes
• change management processes that track all changes are in place along with rollback and test plans
• capacity and bandwidth are actively managed and monitored
• all management actions are accountable (unique accounts allocated to individuals)
• all management should be through secure ingress from trusted locations
• egress filtering should be in place to block all non-legitimate traffic

Security standards are like getting a driving license

When will people learn that compliance does NOT equal security? I blogged about this back in September 2009. Recently Global Payments has suffered a breach despite being PCI-DSS compliant (article from The Register)

Security standards, and being assessed against them, are like getting a driving license. Passing your driving test means that you have achieved a minimum standard of driving, but it doesn't mean that you are a good driver or that you will never have an accident. The same is true of compliance to a particular standard - it doesn't mean that you can be any less vigilant about security or that you will never be compromised, it just means that you have met an agreed minimum level.

People forget that the PCI-DSS is only concerned about payment card data and won't necessarily look at all systems and processes. It is perfectly possible that a system is legitimately considered out of scope, but that the compromise that system allows a platform to attack a system that is within scope. The penetration tests performed are usually more focused on external access to PCI data as well. What if I can compromise the administrator's laptop though? Attacks from more adept hackers won't always go straight for the target; there are often easier ways.

PCI-DSS, and any other standard, should not even be considered the minimum requirement. It should be a given that the organisation will pass their compliance as they should be aiming so far beyond the standards. I realise that resources are not unlimited, but that doesn't mean that you should be satisfied with scraping through audits. If fewer resources were wasted trying to fudge results to pass compliance then more could be spent on actually securing the environment and compliance would be practically automatic.

The goal is a secure, trusted environment, not getting a bit of paper from the auditors.

Trusteer's Response to Issues with Rapport

I have been getting a lot of hits on this blog relating to Trusteer's Rapport, so I thought I would take a better look at the product. During my investigations, I was able to log keystrokes on a Windows 7 machine whilst accessing NatWest. However, the cause is as yet unknown as Rapport should be secure against this keylogger, so I'm not going to share the details here yet (there will be a video once Trusteer are happy there is no further threat).

I have had quite a dialogue with Trusteer over this potential problem and can report that their guys are pretty switched on, they picked up on this very quickly and are taking it extremely seriously. They are also realistic about all security products and have many layers of security in place within their own product. No security product is 100% secure - it can't be. The best measure of a product, in my opinion, is the company's response to potential problems. I have to admit that Trusteer have been exemplary here.

Why do I keep saying it's a potential problem when I have logged keystrokes? Well, under normal operating conditions this isn't possible with the keylogger used. Most home users won't have a machine set up like the test machine in this case.

Trusteer have also pointed out that keyloggers are not the main threat facing the banks at the moment and are of less use now than in the past. Rapport has several layers of security protecting the machine beyond keyloggers and blocking screen capture. One of he major plus points about Rapport is their anti-phishing and anti-pharming technologies. Although, again, these aren't perfect, it's better than nothing.

I don't agree totally with Trusteer here though. The problem with being able to log typed characters comes back to weak passwords and single-factor authentication. In this case, NatWest seem to require a customer ID, consisting of the user's date of birth and a 4 digit ID in the format ddmmyyxxxx, a 4 digit PIN and only a short password. Now, they will let any Customer ID through in this format whether it's valid or not (good from a security point of view as you don't know if you've got a valid Customer ID or not). However, clearly they allow 6 character passwords and then ask for three of them. So with one capture I can have 3 out of 4 PIN digits and half the password. We know people choose weak passwords that can be guessed. This becomes a crossword puzzle to make a 6 character password given three known characters. I would agree with Trusteer that keyloggers and screen capture shouldn't be a problem now, but it still is, as the banks cling onto simple username and password authentication, often with poor password policies.

If the banks move to 2-factor authentication and one-time passwords then most of this would be redundant, and Trusteer could concentrate on pushing us off to the correct site to avoid phishing and pharming attacks. Of course, these will become even more prevelant and sophisticated. Technology can't stop this alone, it has to be coupled with user education. Screen capture can still cause problems with strong authentication solutions, such as those using images or on-screen grids to generate one-time passwords.

So, what's the bottom line? Since my earlier posts, Rapport has come a long way with compatibility, etc. The tone of the marketing has also changed for the better and is more realistic (although some of the 44 partner banks could be doing more). So Rapport could be an additional layer of security to protect you, but you will still have to be vigilant. You must have an up-to-date, legitimate anti-virus/anti-malware product, firewall protection, tight controls on your browser and a cautious and skeptical approach to all communiations and links. Without these, Rapport isn't going to help you anyway.

Edit: video in later post - Keylogging Trusteer's Rapport

Pragmatic Approach to Security

When dealing with security, we must be pragmatic. The resources that an organisation can dedicate to security are limited in terms of time, staff, budget, expertise, etc. Also, perfectly secure systems do not exist - accidents, attacks and penetrations will happen in the end, so plan to deal with them at the outset. Recovery after a breach must be just as much of the planning as the mitigation of the breach in the first place. We all insure our cars, hoping never to call on it, and then try desperately to avoid having any accidents, getting the car stolen or vandalized. However, in the end, a lot of us will end up claiming on the insurance at some point, no matter how careful we are. The same is true of security.



We have to see the bigger picture and align the use of resources with the company's mission. There comes a point when a small amount more security costs a lot more money, time, management effort and is much less user-friendly. Wouldn't it impact the business less if we take the hit and recover quickly and smoothly? Often the answer is yes. We have to find the optimal solution for that particular organisation. The graph above shows that as we increase the security of our system the cost associated with breaches of security comes down, as we have fewer breaches. However, this cost will never be zero, as we will always have breaches. Indeed, breaches may still cost a lot of money but, hopefully they will be few and far between. Conversely, as our security increases, the cost of our countermeasures goes up. Therefore, the total cost will decrease with more security initially, then increase again as the countermeasures become increasingly expensive for less and less improvement to security.

These curves and the overall graph will be different for each organisation. The point I'm trying to make is that we should accept that there is no perfect security, do the best job we can, given the resources allocated, and plan for how we will recover from any breaches in security, be they minor or major. The problem comes when deciding what assets should be given priority and what is the best allocation of resources for a specific organisation. This is where security risk assessments come in. For more about security assessments and risks, see my previous post.

Blackboard (in)Security

The University recently recently paid for a vulnerability assessment and penetration test, which came back saying that, apart from a few minor things, everything was fine and secure. I take issue with this finding for several reasons, most of which I won't go into here. Now, I haven't actually seen the report produced by the company, but I have had verbal reports from the IT technicians that 'nothing serious' was found.

The University uses a hateful product called Blackboard as a Virtual Learning Management System. This is a web-based application allowing access to learning materials, grades, etc., from anywhere in the world. The problem is that it doesn't use an encrypted connection and uses a simple Session ID cookie to assert that you are an authenticated user. There are two problems with this. Firstly, if I capture your cookie and send it with my HTTP request, then I will be treated as you and can see or do anything as you. Secondly, and much more importantly, is that the username and password are sent in plaintext!

I shouldn't have to explain why this is such a bad idea, but I can't understand why this wasn't picked up as a major security hole. A simple packet sniffer will pick up anyone's username and password, giving full access to the network and other services, such as email, home directories, etc. The trouble is that it's not just students who login to this service, all the academics and admin staff do as well. You can imagine what could be done by grabbing a lecturer's username and password.

How easy is it to actually launch a sniffing attack? Well, surprisingly easy (unless you are a pen tester, in which case it won't surprise you at all). Consider the fact that people do connect to this service from public wireless hotspots or from shared networks, such as the halls of residence or the university network itself. It isn't difficult for someone to sniff the network and extract the user's password. 'MAJOR SECURITY WEAKNESS' not 'nothing serious'.

I advise people to connect to Blackboard instances via SSL connections at the very least. It doesn't stop all the attacks, but it will stop simple packet sniffing.

Personal Mobile Devices Violate Compliance

Computer Weekly recently conducted a survey via Twitter on how many organisations allow their users access to corporate email from their own private phone. Unfortunately, I haven't seen any results from this survey as yet, but it made me think about organisations that do allow private devices to attach to the network, not just mobile phones. I have also had many comments on my blog post entitled 'Mobile Device Data Breaches', which have fed into this post.

In one of those comments, someone pointed out that in their experience users are often a weak link. Isn’t it always the case that users are the weakest link? A poorly educated/trained user can compromise the best security. Unfortunately, I have seen so many organisations that do not adequately train their users or make them aware that there are policies, let alone what they mean to their daily usage of the corporate systems. I have also come across one organisation where a top executive had all the system passwords stored, unencrypted, on his PDA. He didn’t see a problem with this as he always carried it with him!

How many organisations these days have push email onto a mobile? How many of those organisations send sensitive documents around via email? Do they have encryption and password access on those devices? Not many that I’ve seen. The typical Blackberry users that I see have no password or PIN access to their phone, but it does have full access to the corporate mail exchange. These devices also have the ability to store, and even sync, corporate documents. What policies do you have to cover them?

Quoting from ISO-27002:2005 11.7.1: A formal policy should be implemented, and appropriate security measures adopted, for mobile computing and communications activities. Controls should apply to laptop, notebook, and palmtop computers; mobile phones and "smart" phone-PDAs; and portable storage devices and media. Controls include requirements for:

• physical protection;
• data storage minimization;
• access controls;
• cryptographic techniques;
• data backups;
• anti-virus and other protective software;
• operating system and other software updating;
• secure communication (e.g., VPN) for remote access; and
• sanitization prior to transfer or disposal.

The problem is that most organisations do not have adequate policies covering mobile devices. Moving away from mobile phones, are you allowed to plug a USB device into your corporate machine? Many of these devices can store sensitive data and even access the Internet themselves. What about an insecure iPhone connecting to the Internet and leaking data? Most organisations aren't even aware that you can lock down USB usage via tools, but policies should definitely be in place. Alan Goode, from Goode Intelligence, said the following:

"I feel that you can lock down with security policy and tools but this is a complex problem as the combination of mobility and technology diversity, e.g. I can use my iPhone to connect to the enterprise network and store sensitive data on it, is creating a major headache for infosec professionals. As well as the problem with laptops and USB drives we are also seeing a growing use of employee-owned mobile devices, netbooks, games consoles, smart phones, all having IP and WiFi capabilities and all capable of picking up enterprise data and email."

There are a number of things we can do to stop these devices from compromising the network by blocking their use. We can block USB devices from being able to connect unless they are a managed resource, so that users can't just plug anything they bring in from home. All USB devices have an ID, which can be registered with a central authentication server to check before a computer allows it to be used. Of course this needs third-party software, but can be done quite easily. We can also block devices from being able to obtain an IP address or connect to the corporate network in the first place. We shouldn't have a free-for-all attitude on the network. It should be locked down to approved devices only. Only managed devices can connect and they will have to authenticate.

I think it’s asking for trouble to allow users to connect their own private devices to the network or services. I don’t see how you can comply with any standards or your own security policies when allowing this, as you don’t know what’s connected or how it’s configured. Even if they are secure (a very big IF), by not knowing the configuration or being able to audit it, you are surely in violation of any accreditation or certification that you may have because you cannot test or 'prove' your compliance.

Compliance does NOT Equal Security

Comodo Vision Video Blog

Responsibility for the notorious Heartland Payment Systems data breach late last year has been debated recently, with Heartland’s CEO suggesting that their PCI auditors let the firm down, while the auditors insist they can’t be responsible for checking absolutely everything. This case brings to light the reality that absolute security is an impossible goal, and that audits are only as good as an organization’s vigilance in following proper security procedures after the audit has been completed.

See my second video blog here.

IPICS OCTAVE-S

OCTAVE-S stands for Operationally Critical Threat, Asset and Vulnerability Evaluation for Small organisations. It is a version of the full OCTAVE methodology aimed specifically at small to medium sized organisations, i.e. those with up to 100 employees. OCTAVE is a risk-based strategic assessment and planning technique for security. It is a top-down approach that is driven by the business's missions and objectives, and is not technology focussed. OCTAVE-S is simply a streamlined version of OCTAVE, with simple worksheets and less expertise required. The outputs of OCTAVE-S should be similar to those of OCTAVE, it is just that it may be possible to shortcut some of the process in smaller orgnisations. OCTAVE itself is designed to be applicable to any organisation, no matter how large.

The Main OCTAVE principles are as follows:

• Core Information Security Risk Evaluation Principles
  • Self-directed
    • The organisation takes responsibility for the evaluation
    • The organisation makes the decisions
  • Flexible / adaptable in the face of...
    • Changes to best practices
    • Evolution of known threats
    • Technical weaknesses
  • A defined process
    • Responsibilities are set out and assigned to people
    • How activities should be performed is documented
    • Standards are set for documentation/artefacts : tools, worksheets, catalogues etc.
  • A continuous process over time
• General Risk Management Principles (general principles beyond InfoSec)
  • Forward looking – proactive
    • Identify future asset that may be significant
    • New classes of threat
  • Focus on critical few
    • Resources are always constrained
    • Avoid spreading effort too thinly
  • Integrated management
    • Information security as routine consideration for general business strategy
• Organisational / Cultural Principles
  • Open Communication
    • Information sharing : avoidance of blame/judgment
  • Global perspective
    • Consult widely and integrate all views
    • Widen perspective to organisational goals
  • Based on teamwork

To find out more about OCTAVE-S visit the website, where you can download the Implementation Guide, which contains introductory materials as well as the actual guidelines and worksheets.

IPICS Risk Assessment Slides

These are my slides on Information Security Risk Assessment, presented at the Intensive Programme on Information and Communication Security (IPICS). The topics covered are: the System-Holistic Approach to ICT Security; Risk Assessment approaches, strategies & terminology; Three Card RAG / Obstacle Poker; OCTAVE^® - Operationally Critical Threat, Asset and Vulnerability Evaluation.

A PDF of the slides can be downloaded from here. (updated)

I will publish more information on the topics covered in due course (and if anyone asks). However, more information on Three Card RAG / Obstacle Poker can be found in a previous blog post.

The PCI DSS and Why It's Relevant to Everyone

Many of you will know that PCI DSS stands for the Payment Card Industry's Data Security Standard and most of the rest of you have probably heard of it and wondered what it was. You may immediately say I'm not interested in the Payment Card Industry and want to navigate away, but just before you do, you should know that many of the 12 recommendations are relevant to all. Actually the PCI DSS recommendations are mostly common sense that we should all be implementing anyway. I'll give a quick overview of the big 12 and how these can be applied to all networks in this blog.

According to the PCI Security Standards Council, "The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized." The 12 recommendations that they put forward can be generalized as follows and should be adhered to by all organisations:

1. Install and maintain a firewall configuration to protect private/sensitive data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored data
4. Encrypt transmission of private/sensitive data across open, public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to private/sensitive data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to private/sensitive data
10. Track and monitor all access to network resources and private/sensitive data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security

Dealing with each very briefly, I’ll try to show how these can be applied to a ‘normal’ network rather than one involved in dealing with payment details. Firstly, we all know that we must have a firewall and block access from the outside world. However, just having a firewall isn’t enough, if it isn’t configured and managed properly. Every port and service open through it must be justified and have clear documentation. There must be policies and procedures in place to control the opening of ports and services through the firewall so that each one can be assessed for its impact on the overall security. Wireless networks should also be separated from wired networks by the firewall – this doesn’t mean that the wireless network has to be unsecured from the Internet or that it has no access to the wired network, just that restrictions and filtering should be in place between them. Obviously, there should be no access from outside the network into the network, as a DMZ should be set up for all public access machines. Finally, personal firewalls should be installed on all mobile machines and hardware firewalls installed at users’ home premises if external access is to be allowed.

The second should be obvious and doesn’t really need any explanation, other than to say disable as many features as you can and don’t allow any configuration or management from outside your network. There are ways to enable secure remote access to the network, thus allowing for management of servers and devices to be achieved from within the network.

The third and fourth requirements go together and mean that strong authentication is required and permissions set appropriately. However, we should also implement encryption on highly sensitive data and removable devices/mobile machines, with proper key-management processes, and Digital Rights Management (DRM) to prevent digital leakage. All data transmitted across public networks should be encrypted (whether sensitive or not).

Is there anyone who doesn’t follow point 5? You’d also think that the zyxst (6th) recommendation would be followed by all organisations, but this isn’t the case. You must have proper patch management procedures as these are critical to securing potential vulnerabilities. However, how many times do you see that the state of the server or service is lagging behind the latest patches? I have seen many commercial outfits developing web applications that are not secure as security is an afterthought and not embedded in the development cycle. This means that, even if you don’t write your own applications, you must check third party applications that you intend to use on your network. Make sure that they have been developed using secure coding guidelines and have been independently tested. An example of not taking it for granted is Apple, who has no formal security program (ref.).

The seventh recommendation sounds obvious again, but it isn’t followed even by many of those covered by the PCI DSS. Restrict access to your data by business need to know. Does your network administrator need to know everyone’s personnel details and payroll? No, so make sure they don’t have access. This is an often overlooked problem, but many organisations rely on people not looking rather than actually protecting the data. How many examples can you quote of companies, and government organisations, losing confidential data that they should never have been able to access? An example springs to mind of a large retailer that lost the names, addresses and credit card numbers of millions of customers, which were copied onto a laptop. Why would you need all this data? Presumably you want it for business intelligence purposes and data analysis. This can, and should, be delivered live through secure channels, not done from a local copy. Why do you need their credit card number though? The point is that it shouldn’t be possible to extract this data and store it on the laptop in the first place. The next two are also related to this and a previous point of requiring strong authentication, which means that you must not allow sharing of user accounts by employees (especially executives giving passwords to PAs!).

Recommendations 10 and 11 deal with monitoring and testing the network. In order to make sure that your system is functioning as expected and that your security mechanisms are appropriate and don’t have vulnerabilities, you need to monitor the network and regularly test it for vulnerabilities. Every time a significant change is made to the network, its impact on the network should be assessed and tested.

The final recommendation is to maintain an information security policy. This must cover all forms of information though, not just electronic. It should be very clear and all employees should be trained in its content and abide by the policy or face punitive measures. Employees should have to sign a copy of the security policy, stating that they have read it, understand its content and agree to abide by it. However, this has no teeth if you do not adequately train all of your employees and update them regularly on the policy and any changes.

The PCI DSS recommendations can and should be adopted by all organisations, not just those involved in payment card transactions.

Obstacle Poker for Security Assessments

I was talking to Vic Page, a colleague of mine, today about various things and he told me about one of his PhD deliverables on 'Three Card RAG' or 'Obstacle Poker' - very interesting concept that he has come up with. During our discussion, we came up with an embryonic idea for using his concept to aide security assessments of organisations. Before I can describe it I need to extract a few concepts from his 10-page paper in the BT Technology Journal entitled "Security risk mitigation for information systems".

In the paper he describes the Security Obstacle Mitigation Model (SOMM) for developing trustworthy information systems. He also defines some terminology - a subset of which I have reproduced here (his paper is an interesting read):

• mitigation - a mitigation is a procedure that will counter the effect of an obstacle


• obstacle - an obstacle is something that, should it occur, will obstruct a trust assumption and affect the CIAA security requirements - obstacles are caused by malicious or inadvertent use of the operational information system


• RAG code - RAG codes form an intuitive 'traffic light' approach to ranking the ability for load-bearing and the vulnerability of a trust assumption (RAG is an acronym for Red, Amber and Green). R signifies stop and mitigate, A signifies proceed with caution and G signifies continue with trust

So how is this relevant to security assessments particularly rather than information systems in general? Well, it is the way he is applying it that becomes interesting for the security assessment arena. He has moved this concept into the field of agile development and taken the Scrums process of planning poker and made it more accessible for other fields.

Now a quick background to the security assessment field is in order. The majority of security assessment strategies are technology focused and concentrate on system evaluation and tactical issues. This can lead to point solutions and, therefore, gaps between countermeasures. Obviously we need the vulnerability assessments and information system audits, but these should follow an Information Security Risk Evaluation. Schemes like Octave, although big, do follow an organisational evaluation, focused on security practices and strategic issues. The top down approach is driven by business issues and objectives leading to protection of what needs it and awareness of risk. Most other bottom up security practices start with individual components and computing infrastructure, seeking the technological 'silver bullet', which leads to protecting what can be protected rather than what needs to be protected. Of course this is an ongoing cyclical process.

So, what is obstacle poker and how do we incorporate it into an information security risk evaluation? Well, the principle is that representatives of all roles must be included in an information security risk evaluation for it to meet the needs of the organisation. Too often security assessments are left to the ICT departments and technologists, who don't necessarily know the business processes at play. Unfortunately, the people working in the organisation who aren't part of the ICT team usually have little or no knowledge of the technical landscape or what's possible/feasible. It needs everyone at the table and they need to speak a common language. Interpreters, i.e. consultants, can be brought in to help, but there still needs to be a simple way to converse.

The idea of 'Three Card RAG' is that an issue is discussed and then all the members of the team will rate it with the RAG scale given above. This is done by issuing each member of the team three cards - one Red, one Amber and one Green. Each member picks a card and then everyone reveals their cards at once. If everyone agrees, then that is considered the state of play and actions are taken accordingly. If they do not agree then further discussion can be entered into and another round completed. The idea being to come to a consensus between the technical experts and the users of the system quickly and efficiently. Those that are more obvious will be dealt with very quickly, those requiring more discussion will be given a fair hearing.

This principle can be used in information security risk evaluation by identifying the threat ratings and consequences of risks. We all know that a Threat + a Vulnerability = Risk to an Asset, but how can we categorise these when ICT and management departments can be approaching this from very different standpoints? Is the system that seems critical to the ICT department actually critical to the business or not?

Threat ratings have the following defined ranges: Negligible, very low, low, medium, high, very high and extreme. They are quite well defined in terms of how often they are likely to occur, from unlikely, through likely to occur every 6 months or less for medium, to likely to occur multiple times each day for extreme. These threat ratings must be ICT lead, but not exclusively controlled. If everyone holds a green card then it can be classified as very low or negligible. Amber would denote Medium and red would denote very high or extreme threat rating. Mixtures of cards can result in the low or high ratings being used if there is still no total agreement after a few rounds. The consequences are where the ICT department may step back a little. These are defined by the Australian Government's Defence Signals Directorate as:

• insignificant - can be dealt with by normal operations
• minor - could threaten the system’s efficiency or effectiveness but can be dealt with internally
• moderate - does not threaten the system, but could cause major review and modification of operating procedures
• major - threatens the continuation of basic functions of the system and requires senior-level management intervention
• catastrophic - threatens the continuation of the system and causes major problems for the organisation and customers

This is where Three Card RAG really comes into its own. Getting agreement on this scale can be very difficult in organisations. However, with a simple traffic light scheme, everyone understands the system and agreement can be reached much more easily between all the stakeholders. Simply put, if it's red it's a priority, amber is secondary and green can be safely ignored until the next iteration (N.B. not ignored completely or never discussed again, just not dealt with in the current round of the cycle).