Information Security for Business-Where to Start

Update 5th July 2015, 28th June 2015

Where does a business or organisation start if they want to improve their information security stance?

Here are some ideas. The links are at the bottom of the post.

Council on CyberSecurity Critical Security Controls

• "The Council's Technology practice area is built upon the Critical Security Controls (the Controls), a recommended set of actions for cyber defense that provide specific and actionable ways to thwart the most pervasive attacks"

This is related to the Sans Institute Critical Security Controls - See below

The council also has its "First Five Quick Wins"

1.  application whitelisting (found in CSC 2);
2.  use of standard, secure system configurations (found in CSC 3);
3.  patch application software within 48 hours (found in CSC 4);
4.  patch system software within 48 hours (found in CSC 4); and
5.  reduced number of users with administrative privileges (found in CSC 3 and CSC 12).

These are related to the Australian Signals Directorate Top 4 - See below

SANS Institute Critical Security Controls

The SANS institute maintains a list of the top 20 critical security controls.

• The Critical Security Controls focuses first on prioritizing security functions that are effective against the latest Advanced Targeted Threats, with a strong emphasis on "What Works" - security controls where products, processes, architectures and services are in use that have demonstrated real world effectiveness

Australian Signals Directorate Top 4

The Australians Signals Directorate (ASD) maintain that:

• "At least 85% of the intrusions that ASD responded to in 2011 involved adversaries using unsophisticated techniques that would have been mitigated by implementing the Top 4 mitigation strategies as a package.

The  top 4 are:

1. Application Whitelisting
2. Patching Systems
3. Restricting Administrative Privileges
4. Creating a defence-in-depth system

--

Here are a number of programs from the The UK Government.

Cyber security guidance for business 

This guidance is aimed at business in general and starts off with board level responsibilities.It then describes  the "10 steps" to cyber security" which cover the following topics

1. Information Risk Management Regime
2. Home & Mobile Working
3. User Education & Awareness
4. Incident Management
5. Managing User Privileges
6. Removable Media Controls
7. Monitoring
8. Security Configuration
9. Malware Protection
10. Network Security

 Cyber Street Wise

Cyber street wise has the following "five essential tips for cyber safety" for your business

1. Install Updates and antivirus software
2. Use strong passwords
3. Only download from trusted sites and organisations
4. Beware of phishing emails
5. Review and protect your business' information

Cyber Essentials

First comes "Cyber Essentials"  which "is a government-backed, industry supported scheme to help organisations protect themselves against common cyber attacks."

This is more technical and covers the following five areas.

1. Boundary firewalls and internet gateways
2. Secure configuration
3. Access control
4. Malware protection
5. Patch management

It also states the following

"From 1 October 2014, [UK] government requires all suppliers bidding for certain sensitive and personal information handling contracts to be certified against the Cyber Essentials scheme."

Useful Links

• Council on CyberSecurity Critical Controls
• SANs Institute Critical Security Controls
  
• Australian Signals Directorate Top 4 Mitigation Strategies
• Cyber Street Wise 
• Cyber security guidance for business 
• Cyber Essential Scheme

   

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

FUD: A Plea for Intolerance

Another interesting paper from Cormac Herley at Microsoft Research

In it he talks about "Fear, Uncertainty and Doubt" (FUD)  and how

"Even a casual observer of computer security must notice the prevalence of FUD :non - falsifiable claims that promote fear, uncertainty or doubt (FUD)"

It is short at 5 pages and well worth reading.

Useful Link:

• FUD: A Plea for Intolerance

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

EU Data Protection Regulation - Application Security

Update: June 28th 2015

Progress is being made.....slowly. Here is a link to the version proposed by the European Council
http://data.consilium.europa.eu/doc/document/ST-9565-2015-INIT/en/pdf



The new EU Data Protection regulation took another step on its long road towards becoming law.  What does this mean for application design and security?

Originally proposed by the EU Commission in January 2012, the EU Parliament has now supported it (with lots of amendments to the original proposal). The next step on the long road is the EU Council of Ministers.

Who knows when/if this becomes law, but it is worthwhile being aware of it. It is long and complicated and will change.

What could this mean for application design and security? Here are some of the proposed amendments which may impact your application design and security when processing personal information of EU citizens. These are just the barest details based on the amendments proposed by the  EU parliament. There is more information in the links below.

Article 15 - Amendment 78 - Right to Rectification and Completion

In this amendment, the data subject can request that any information be corrected. For the application developer, this means that there should be some way to correct personal information that the application stores.

Article 16 - Amendment 79 - Right to Erasure

The data subject can request that their personal data be deleted. There are various conditions around this. Basically it means that application should have the ability to delete a user's information at their request.

Article  19 - Amendment 81 - Data Protection by Design and by Default

This is a core article from a security perspective. It talks about "protection by design", "risk", "entire lifecycle management of personal data from collection to processing to deletion". 

Security of personal data cannot be an afterthought. It must be considered from the start of the application design. 

Article 24 - Amendment 86 - Keeping of Records

This article essentially means that the application must keep an audit trail. It even mentions such items as "date and time". 

Article 27 - Amendment 90 - Security of Processing

This is another one directly related to application security. The main clause states that the data controller or processor must:

"implement appropriate technical and organisational measures and procedures to ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected, having regard to the state of the art and the cost of their implementation."

Again this clause mentions risk. The article itself lists a number of more detailed requirements covering such security measures such as access control etc.

Useful Links

• EU Data Protection 12th March 2014 - Amendments proposed by EU Parliament

• http://www.theregister.co.uk/2014/03/12/european_parliament_waves_through_data_protection_reforms  

•  EU Press Release 12th March 2014 - Progress on EU data protection reform now irreversible following European Parliament vote

•  25th January 2012 - EU Commission proposes a comprehensive reform of the data protection rules

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

NIST Cybersecurity Framework

The NIST has just released the Cybersecurity Framework Version 1.0. This is mainly intended for improving critical infrastructure type facilities in the USA. However, it can potentially be applied to a much broader range of organisations across the world.

It covers 5 main functions of a cyber security framework.

• Identify
• Protect
• Detect
• Respond
• Recover

Each of these functions is then broken down into categories and the categories are further sub divided into subcategories.

This is two more than Bruce Schneier who defines Protect, Detect and Respond.

The basic idea is that you take the categories and analyze it to define your current profile. You then define a target profile and work out action plans and prioritizations to achieve the target profile.

It is not a very long document and much of the useful information is stored in the appendixes. It widely references other public standards.

Application Security

The framework does not have much to say about secure application development.  However it is extensible so you can add in your own categories and sub categories. It does talk about access control, data-at-rest and data-in-transit controls etc.

PR.DS-7 says:

The development and testing environment(s) are separate from the production environment

Useful Links

• NIST Press Release 
• http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Data Flow Diagrams and PCI DSS Version 3

I just noticed that the Payment Card Industry - Data Security Standard (PCI DSS) Version 3 has a new requirement at 1.1.3. The old 1.1.3 in PCI DSS version 2 is now requirement 1.1.4 in PCI DSS version 3.

PCI DSS Requirement 1.1.3

So what does new requirement 1.1.3 say?

"Current diagram that shows all cardholder data flows across systems and networks"

The testing procedure for this requirement says

"Examine data-flow diagram and interview personnel to verify the diagram:

• Shows all cardholder data flows across systems and networks.
• Is kept current and updated as needed upon changes to the environment.

And finally the guidance says

"Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices."

The Fundamentals

Data Flow Diagrams (DFD) are a powerful tool in many situations. Whether in the role of PCI QSA or security architect where you are trying to work out the appropriate level of security requirements. This new PCI requirement recognizes this. While PCI really only cares about payment cards, DFDs can and should also be used wherever you are analyzing data which is important to your organization.

A DFD consists of three main sections:

1. It shows the data flows - i.e. the networks etc. through which data passes.
2. It shows data storage areas. This indicates where data is stored within the system 
3. Finally the DFD highlights trust boundaries. This is where data travels across boundaries which are not trusted. The interface to the internet is typically a trust boundary.

A DFD need not be complicated. At its simplest it consists of a series of boxes indicating the data storages on a whiteboard while lines showing where data flows.

When creating a DFD, make sure to ask a series of questions such as:

• Where are backups held? 
• How are test systems and data handled. Remember, if live production data is used in a test system, the same level of security must apply as in the production system.
• Can users export data to desktops etc.?

These questions help build up a complete DFD picture.

When you have a good DFD, then you can start specifying the appropriate level of security controls that are required for each flow and storage within the DFD. For example, if sensitive data flows across the public internet then it should be encrypted using SSL. A DFD helps answer these types of questions.

DFDs and Application Security

DFDs apply when developing applications and choosing security controls. They help working out what type of security controls are required whenever data is at rest or in motion. When developing the security requirements for the application, the development team should develop appropriate DFDs. This should be done early in the development life cycle.  The DFDs can then be used to make sure that the proper security controls are in place which reflect the security drivers for the application. These security drivers can include data protection legislation, PCI DSS, internal corporate policies.

Useful Links

• PCI Security Standards Council
• PCI DSS Version 3
• Wikipedia: Data Flow Diagram

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Mobile Phone Security Malware Statistics - Mobile Application Security

Which of the following statements do you believe? 

1. "Given that there are around 1.5 billion smartphones and tablets in the world, that means probably fewer than 15,000 of them are harbouring mischievous software." -  The Economist -  November 2013
2. "32.8 Million Android Phones Infected with Malware" - Techlicious.com - April 2013 based on information from NQ Mobile

(As a long time "Economist" reader, I probably tend to go with number 1.)

Does it matter?

If you are trying to make informed decisions around mobile phone security for yourself or your organisation, then it does matter. Go with statement number 1, then you will be trying to implement controls to ensure around the risk that the device will be lost or stolen (encryption, backups etc.)

Favour statment number 2, and you will be thinking more about security controls like anti-virus applications etc.

The Economist article goes on to say:

"Gartner, an information-technology consultancy based in Stamford, Connecticut, advises clients not to worry too much about malware penetrating their networks through the devices employees bring to work. It is the users themselves who are the problem. How, for instance, do companies prevent employees from innocently responding to “spear-phishing attacks” in the form of individually targeted, and very official-looking, e-mail or text messages, apparently from trusted colleagues, that request sensitive information? Security measures need to focus more on educating users, says Gartner, rather than on the relatively minor problem of mobile malware. "

Mobile Application Security

What about mobile application security? The OWASP Top 10 Mobile 2014 risk "M2 - Insecure Data Storage" says about the threat agent:

"Threats agents include lost/stolen phones and the possibility of in-the-wild exploit/malware gaining access to the device."

If you believe The Economist, you will give less weight to the malware risk in your application design and more prominence to the lost/stolen phone risk.

If the device itself is properly encrypted, then you will be less concerned about storing sensitive data on the device. Since the risk of malware is low, then it is unlikely that malware will steal the sensitive data.

(Ok - you should still  be careful about what data your application stores on the device.)

Useful Links

• Sex Lies and Cyber-crime Surveys - Microsoft Research
• OWASP Mobile Top 10 Project

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Can InfoSec Actually Help Save Money

Can Information Security actually help save money? 

In terms of InfoSec, we usually think of the possible potential for future savings. Hopefully, the thinking goes, if we invest in appropriate security controls now, we will not be hacked in the future. Calculations based on this approach, such as Return On Security Investment (ROSI)  try to make this argument. It's an insurance policy.

But the present question is can we use InfoSec to actually achieve verifiable savings, now?

Availability

The third leg of the InfoSec triad is Availability (the other two, as you already know, being Confidentiality and Integrity). In general, availability means having information available when you need it. But the flip-side of this is what to do with information when you no longer require it. Can we make savings here?

In general, companies and organisations tend to keep information for ever. We are afraid to get rid of it, because we might need it for a rainy day. However there is a cost associated with this. Even though storage costs keep going down, the amount of information that we generate keeps increasing. And it costs money to store all this data. Hardware costs, personnel, backups etc.

If the data can be deleted, then can these associated costs can be saved?

The possible answer is to delete it when it is no longer available. In fact, data protection legislation usually says something along the lines of "Delete personal data when it is no longer needed". If we can achieve this, then not only are we likely to save costs, but we are also more likely to be in compliance with legislation.

What are the necessary steps?

Data Retention Policy

Develop a data retention policy. This will define how long data is to be kept and when it can be deleted. This may give rise to conflicting requirements based on the type or classification of data that is being processed. As mentioned earlier, personal data should be deleted when no longer needed. However, financial  or transactional data may need to be retained for a certain amount of time for audit purposes. Important is to identify the different types of data that you process - and then to define retention periods for the various classification types. 

This bit can be tricky as you need to consider other issues such as information that may need to be retained for litigation purposes.

Identification

The next step is to identify the locations where information is stored and to classify these based on the data retention policy.

Deletion

Finally, delete the data  based on the data retention policy and on classification type.  Then you can reuse the freed-up space for newer data.



Money saved.....hopefully!!

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot