Application and Data Security Framework...An example is the security breach at Digi-notar Certificate Authority, as described in the report “Diginotar Certificate Authority breach

Rijndijk 235

2394 CD Hazerswoude Tel. (071) 3416911

Email [email protected]

Author Edward van Egmond Thesis number 1068 e-mail address [email protected] Student number 0-682918 Status Final Date 28 January 2013 Employer Noordbeek B.V. Filename Application and Data Security Framework

1 van 34

Application and Data Security Framework

Version: 1.00

Vrije Universiteit Amsterdam

Application and security framework

2 van 34

Author Edward van Egmond

0-682918 Noordbeek B.V. Rijndijk 209-B 2394 CD Hazerswoude

Supervisor René Matthijsse Capgemini Outsourcing B.V. Papendorpseweg 100 3528 BJ Utrecht

Local Supervisor Dennis Oosterwijk Noordbeek B.V. Rijndijk 209-B 2394 CD Hazerswoude

Thesis number 1068



3 van 34

Content

1. Introduction .......................................................................................................................... 4 1.1. Research motivation ...................................................................................................... 4 1.2. Research Problem .......................................................................................................... 6

2. Summary ............................................................................................................................... 9

3. What is the scope of the risk framework? ........................................................................ 10

4. Which risk methods are currently available? .................................................................. 10 4.1. The researched methods .............................................................................................. 10 4.2. ISO 27001:2005 Information Technology .................................................................. 10 4.3. PCI DSS 2.0 ................................................................................................................ 13 4.4. OWASP Secure Development .................................................................................... 16 4.5. NIST SP 800-30 Risk Management Guide for Information Technology Systems ..... 20

5. Are all possible risks found regarding vulnerabilities and possible threats? ............... 23 5.1. Risks are unknown ...................................................................................................... 23 5.2. Risks are systematically overlooked ........................................................................... 24

6. And how can a risk framework decrease the vulnerabilities and possible threats of the IT infrastructure? ....................................................................................................................... 26

6.1. e-Competence Centre .................................................................................................. 27 6.2. Risk Register ............................................................................................................... 29 6.3. Intelligence collection and use .................................................................................... 30

7. Conclusion ........................................................................................................................... 31

8. Self reflection ...................................................................................................................... 32



4 van 34

1. Introduction

This document contains the master’s thesis of Ing. Edward van Egmond QSA CISA, Manager IT Audit at Noordbeek B.V. The research reported in this thesis concludes the third and final year of the Postgraduate IT Audit course at the Vrije Universiteit Amsterdam.

1.1. Research motivation

Companies are demanding higher security measurements and certificates, due to the increasing amount of intelligent cyber attacks from the Internet. An example is the security breach at Digi-notar Certificate Authority, as described in the report “Diginotar Certificate Authority breach Operation Black Tulip”1. The hacker eventually gained administrative access to the outer web servers, the Certificate Authority (CA) server “Relations-CA” and the server “Public CA”. This resulted in the issue of more than 500 rogue certificates. Among them was the root certificate of google.com which is used for most of Google online services, for instance gmail.com. The main targets of the attacker were Iranian Internet users. Dutch government sites and several other sites were temporarily declared unsafe as a result of the breach.

A legitimate website can be setup with false certificates which cannot be detected as false2. All sent information is accessible to the owner of the website when Internet traffic is lead to this false website. The hacker can use the ‘man in the middle attack’3 even when encrypted data is being used. A ‘man in the middle attack’ is an attack where a criminal intercepts information between two communicating parties e.g. a user and the online banking services. It is similar to a legion of an army which communicates with the general for orders. The information between the legion and the general is exchanged via a courier. The hacker is in this case the person who changes the information while the courier stops for fresh horses. The hacker controls the infor-mation and both the legion and the general sees what the hacker wants them to see.

A side effect of this security breach was the fact that the Dutch government had to temporarily freeze the websites of DigiD and other online services, for example the Dutch Revenue Services (Belastingdienst). In a short period the Dutch government had to switch all their certificates over to a new Certificate Authority. The procedure to renew all certificates had a great impact on the availability of the Dutch government’s online services.

According to The Open Web Application Security Project (OWASP)4 another sure way to breach web systems is SQL injection. SQL means Structured Query Language and is designed for databases. Common databases which use SQL are Oracle, MySQL and Microsoft SQL. The SQL injection method is currently a 13 years5 old cyber attack method, used to gain unauthor-ized access to information. Entering SQL statements in a web form will get a badly designed website to perform operations on the database other than the usual operations as intended by the

1 J.R. Prins, “Diginotar Certificate Authority breach Operation Black Tulip”, version 1.0 5 September 2011, Publisher: Fox-IT. 2 http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar 3 http://nl.wikipedia.org/wiki/Man-in-the-middle-aanval 4 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. 5 http://www.security.nl/artikel/39679/1/Top_10_grootste_SQL-Injection_datalekken.html.

http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar

http://nl.wikipedia.org/wiki/Man-in-the-middle-aanval

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.security.nl/artikel/39679/1/Top_10_grootste_SQL-Injection_datalekken.html



5 van 34

designer6. This often results in a dump of the database content to the attacker, for example all names and credit card numbers. The vulnerability is that the characters entered in the form are not checked and a SQL statement can be entered and executed. An example of a statement en-tered in the username field: ' or '1'='1;/*. The first ‘ means end of field. An OR is a Boolean statement, the Boolean language consists of TRUE and FALSE. The OR combined with the 1=1 statement, which is TRUE, renders the complete statement as TRUE. It ends the statement with a ;/* to set further data as comments, usually the password field. This entered statement in the username field tells the application to ignore the password field and just let us pass. More elabo-rate statements can be used to query the database and to dump the complete database. This gives the hacker complete access to all information, usually credit card data with the corresponding name, address etc.

As a result 120,000 Dutch sites have been compromised7 due to the DigiNotar cyber attack and the current SQL injection problems. Therefore the demand for higher Cyber security has in-creased. Cyber security according to The National Cyber Security Centrum (NCSC) is “to be free from danger or damage caused by disruption or fall-out of IT or abuse of IT. The danger or the damage due to abuse, disruption or fall-out can be comprised by limiting the availability and reliability of the IT, breach of the confidentiality of information stored in IT or damage to the integrity of that information.”8

To indicate how simple it is to exploit the SQL injection vulnerability: a security investigator would let his three year old son use some default penetration test software and he eventually succeeded breaking into a website9.

Thus a higher level of cyber security asks for a risk driven ability in achieving more insight in determining the risks, threats and vulnerabilities and give a more complete picture of what to expect in the near future. This framework should be the basis of resolving this complex problem of the cyber world.

6 http://en.wikipedia.org/wiki/Sql_injection. 7http://www.security.nl/artikel/39711/1/120.000_Nederlandse_pagina%27s_gehackt_tijdens_aanval.html 8 Bokkerink, Dutch National Cyber Security Strategy, First edition 22-02-2012. 9 http://www.security.nl/artikel/43502/1/3-jarige_hackt_website_via_SQL_Injection_%28video%29.html.

http://en.wikipedia.org/wiki/Sql_injection

http://www.security.nl/artikel/39711/1/120.000_Nederlandse_pagina%27s_gehackt_tijdens_aanval.html

http://www.security.nl/artikel/43502/1/3-jarige_hackt_website_via_SQL_Injection_%28video%29.html



6 van 34

1.2. Research Problem An important question is “Will my information be available tomorrow morning and can I also rely on the confidentiality and integrity of my data?”

2Application and Data Security Framework

threats, incidents, frauds and vulnerabilitiesW

eb

Websoftware

Infrastructure (Cloud)

Application

Housing

DATAMiddleware / Connectivity

Housing

Office A

utomation

Vulnerabilit

ies

Weaknesses

ExternalThreats

OWASPIncidentsFraud, abuse

OWASP = Open Web Application Security Project

InternalThreats

Obstruction, error

Incidents

Fraud, abuse

The research problem is how to get better control with a framework which focuses on the (fu-ture) risks, threats and vulnerabilities of the current application and data security issues. More and more internally faced systems and databases are made publicly available through web por-tals. The web portals are both used as internal and external facing portals. A web portal is a web site that combines information from various sources in a unified way. Usually, each information source gets its dedicated area on the page for displaying information (a portlet); often, the user can configure which ones to display10. The external faced web portal is used for the customers; the internal faced web portal is used by personnel. The use of web portals opens up a variety of vulnerabilities, which can be found at the OWASP website. More vulnerabilities are accessible to hackers when a web portal is used for internal use and for the convenience of the customers. The hacker can enter from the public Internet or might as well be an employee due to the avail-able information on the Internet on how to use SQL injection and other forms of exploits. This increasingly accessible means to unlock information asks for better defined controls for auditing and for implementing security measures. Risks as well as threats and vulnerabilities need con-stant monitoring to keep up with current state of development.

10 http://en.wikipedia.org/wiki/Web_portal

http://en.wikipedia.org/wiki/Web_portal



7 van 34

1.2.1. Main research question

Based upon the research problem the main research question reads: “How can we decrease the risks of vulnerabilities and possible threats to the company IT-infrastructure which also meets the current and future demands of a complex web based application environment?”

The research question becomes more relevant considering the latest threat, the Dorifel virus. The Dorifel virus became active in the second week of August and infected over 3000 com-puters within a few days. Experts expect the real figure of infected computers to be significantly higher.

What makes this threat so dangerous? The Dorifel virus was already present on the computers without the knowledge of the users. The Citadel botnet was responsible for activating the virus. A botnet is a collection of computers also known as zombie computers which have been re-cruited by running malicious software. Botnets are exploited for various purposes, including denial-of-service attacks, creation or misuse of SMTP mail relays for spam, login IDs, and fi-nancial information such as credit card numbers. The Citadel botnet had been used on this spe-cific occasion for harvesting Dutch bank account information. The botnet is used for phishing by displaying fake bank sites with the intention to fool users to give out their account informa-tion and passwords. Criminal organisations use the harvested information, e.g. usernames and passwords, to plunder the bank accounts of the victims and transfer the money via straw men to their accounts.

What did the Dorifel virus do exactly? After activation the virus looked for shared network drives and usb media. Shared network drives are used in organisations to centralize disk space via a file server to minimize the risk of losing data. A backup of the centralized data is simple to implement. The Dorifel Virus encrypted all found Word and Excel files in an executable file. Because of the virus leaving the display symbol, the icon, intact other users were not aware when the encrypted files are executed and the virus infected their computers as well. The virus spread increasingly rapid through companies and Dutch local government through sharing via network drives and usb sticks. The Dorifel virus also stole the browser history and browser cache which enabled the receiver to have a clear idea where to use the stolen usernames and passwords. The risk of fraud or identity theft suddenly became a potential threat.

Experts consider the Dorifel virus not specifically intelligently written. Normally a virus tends to stay hidden as long as possible to harvest more information from the unaware user. The virus has similarities with an older virus, named Induc. Both use the method to encrypt the files in executable files.

Since the end of September 2012 a mutation of the Dorifel11 virus has been detected. This is a more sophisticated form; it is encrypted and changes its appearance to hide its presence to any malware or virus checker. The new Dorifel encrypts the documents of the unaware users just like its predecessor. The encrypted documents need to be decrypted with a new decryptor tool. As with the former version it starts downloading malware, a ZeroAccess Trojan. This Trojan

11 http://www.security.nl/artikel/43268/1/Nieuwe_Dorifel_verspreidt_BumaStema-virus.html.

http://www.security.nl/artikel/43268/1/Nieuwe_Dorifel_verspreidt_BumaStema-virus.html



8 van 34

infects windows system files which makes it harder for anti virus programs to remove this Tro-jan. After that it downloads the Buma Stemra-virus.


Buma Stemra virus

The Buma Stemra-virus is ransomware. Ransomware locks the computer and shows the screen as shown above. The user can not use their computer until they paid the ‘ransom’ of €100,--. The user must insert the valid code of a paysafe card with the required amount. The risk of data loss is a possible if the ransom is not paid and the user re-installs the computer.

Minister Opstelten from the Safety and Justice department (Ministerie van Veiligheid en Justi-tie) stated that the Dorifel virus and the newer variant could not be found with the current anti virus and malware programs. The scale of the outbreak could therefore not be foreseen. On the other hand, experts advise to continuously update your antivirus or malware programs and try to inform users more effectively about the security risks caused by the use of e-mail and usb sticks. According to the experts the outbreak would not have had such an impact if these simple pre-cautions would have been taken.

1.2.2. Subsequent research questions

Before answering the main research question, we need to answer the following questions: ♦ What is the scope of the risk framework? ♦ What risk methods are currently available? ♦ Are all possible risks found regarding vulnerabilities and possible threats? ♦ And how can a risk framework decrease the possible threats and vulnerabilities of the IT

infrastructure?



9 van 34

1.2.3. Research Methodology

The research methodology involves a main research question which states the problem. The main problem is divided in separate sub questions. An overall answer can be defined for the problem by answering these sub questions. When all conclusions or answers are combined an overall conclusion is drafted as a possible answer to the research question.

2. Summary

The thesis researches the possibility of a forward or future based risk assessment framework. The scope is defined and an investigation of current frameworks is performed to give a view of the current risks methods. Another investigation is to determine the current view on threats and vulnerabilities. Are all threats recognized as threats and are vulnerabilities found and mitigated in time to prevent others to gain access? This is a relevant question which impacts risk manage-ment. This thesis tries to provide a new look on current risk assessment and the way risks must be reviewed.



10 van 34

3. What is the scope of the risk framework?

The scope of this framework has a risk oriented point of view. It involves determining threats and possible vulnerabilities. Due to the evolution of current IT infrastructure, application and data security are more vulnerable to threats from outside but also from within the organisation. Future based (or forward looking) risk assessment is the scope of this thesis. Forward risk as-sessment is required because of the readily available exploits of vulnerabilities which are still undiscovered. Most of these vulnerabilities formerly have not been seen as a possible risk. For example, the Microsoft Internet Explorer browser has been vulnerable to zero day exploits for 89 days12. A zero day exploit is an attack on a system or software with the found weakness by hackers and exploit this weakness before the developer can release a patch. In the amount of time before a new patch is released, in this example 89 days, a new risk is introduced. The risk of a hacker using this exploit increases with each day this exploit has not been fixed! The future based risk assessment is continuously looking at what is happening on the Internet at this mo-ment, analysing possible related incidents. Reading security forums, following security experts on twitter or other social media is needed to gain a better understanding of what is currently a threat or vulnerability. This can result in a framework which is continuously kept up to date.

4. Which risk methods are currently available?

4.1. The researched methods

For the thesis, the following list of frameworks or best practices have been researched. The re-search will focus on a set of controls or measures considering Internet facing web applications. The found set of controls or measures are combined and filtered.

The following included frameworks and best practices are researched, but not limited to: ♦ ISO 27001:200513; ♦ PCI DSS 2.014; ♦ OWASP Secure Development15; ♦ NIST SP 800-3016.

4.2. ISO 27001:2005 Information Technology

The IT audit practice uses the most widely used method e.g. ISO 27001 “Information Security Management System”.

12 http://www.security.nl/artikel/43301/1/Zero-day_lekken_89_dagen_misbruik_in_IE.html. 13 International Standard ISO/IEC 27001:2005(E), First edition 15-10-2005, Publisher: ISO. 14 PCI Council, PCI Data Security Standard, Requirements and Security Assessment procedures version 2.0, October 2010, Publisher: PCI security council LLC. 15 Marc Curphy et al, A guide to building secure web applications and web services, second black hat edi-tion July 2005, Publisher: The Open Web Application Security Project. 16 Gary Stoneburner, Alice Goguen and Alexis Feringa, “Risk Management Guide for Information Tech-nology Systems SP800-30”, July 2002. Publisher: National Institute of Standars and Technology (NIST).



11 van 34

This International Standard has been prepared to provide a model for establishing, implement-ing, operating, monitoring, reviewing, maintaining and improving an Information Security Man-agement System (ISMS). The adoption of an ISMS should be a strategic decision for an organi-sation. The design and implementation of the ISMS for an organisation is influenced by their needs and their objectives, security requirements, the processes employed and the size and struc-ture of the organisation. These needs, objectives and their supporting systems are expected to change over time. It is expected that an ISMS implementation will be scaled in accordance with the needs of the organisation e.g. a simple situation requires a simple ISMS solution.

This International Standard adopts a process approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an organisations ISMS.

An organisation needs to identify and manage many activities in order to function effectively. Any activity using resources and management in order to enable the transformation of inputs into outputs can be considered to be a process. Often the output from one process directly forms the input for the next process.

The application of a system of processes within an organisation, together with the identification and interactions of these processes, and their management, can be referred to as a “process ap-proach”.

The process approach for information security management presented in this International Stan-dard encourages its users to emphasize the importance of: a. Understanding an organisation’s information security requirements and the need to establish

policy and objectives for information security; b. Implementing operation controls to manage an organisation’s information security risks in

the context of the organisation’s overall business risks; c. Monitoring and reviewing the performance and effectiveness of the ISMS; and d. Continuous improvement based on objective measurement.

This International Standard adopts the “Plan-Do-Check-Act” (PDCA) model which is applied to structure all ISMS processes. The adoption of the PDCA model will also reflect the principles as set out in the Organisation for Economic Co-operation and Development (OECD) Guidelines17 governing the security of information systems and networks. This International Standard pro-vides a robust model for implementing the principles in those guidelines governing risk assess-ment, security design and implementation, security management and reassessment.

17 OECD Guidelines for the Security of Information Systems and Networks – Towards a Culture of Secu-rity. Paris: OECD, July 2002. www.oecd.org.



12 van 34


ISO 27001 Risk Management


Where are our own vulnerabilities?

ISO 27001 RISKMANAGEMENT

The ISO 27001 used risk method is based upon setting up a risk table with all known risks ver-sus security and business. Threats and vulnerabilities are taken into consideration while deter-mining the risks. Management evaluates the risks based upon impact and likelihood. Priorities are set by management, which risks are considered important and which are less important. Ac-tions or measures already in place are taken into account and an action plan is made. The plan needs to address the highest priorities and is implemented after approval by management. Re-sidual risks are acknowledged and documented. Because of the PDCA character, the risk table is reviewed and updated yearly, which is a requirement of the ISO 27001 certification.

Conclusion

ISO 27001 method of risk evaluation is often used. The author deems this method very good in making management more risk aware of all company assets. With this method of risk evaluation a risk sheet is introduced. A Risk Manager can use such a risk sheet to keep track of all consid-ered risks. This risk sheet can have the following fields (but not limited to): ♦ Risk description; ♦ Owner; ♦ Impact, probability and priority; ♦ Mitigation cost and status; ♦ Impact, probability and priority after mitigation.

Management can keep track of the status of the implementation of mitigation measures, the pri-orities and the cost of the mitigation.



13 van 34

The additional questions regarding this risk method are: ♦ Have all risks been identified? ♦ Are all possible risks known and what is their frequency and impact?

Management often gives more attention to the costs of risk mitigation and decreasing the likeli-hood. This way management can reason away risks and have better acceptance of the residual risk. The problem starts when a risk with high impact and low likelihood is acknowledged by management, for example the risk of a tsunami hitting the coast of the Netherlands.


Example: Doggerland Storegga tsunami

TSU

NA

MI

The next one?: Storegga is now stable. Exploding volcano at Iceland? Meteorite in North Sea? Our location is dangerous

Doggerland Source: ‘Tsunami sedimentary facies deposited by the Storeggatsunami in shallow marine basins and coastal lakes, western Norway’Stein Bondevik, in Sedimentology 1997

Last tsunami in the Netherlands• 2de Storegga slide• Waves up to 25 meter on

Shetland islands• Dated 6,000-6,200 BC• Estimate: October 6,125 BC• Center of (our) neolithic

civilization was Doggerland• This center is destroyed• Thereafter no trace of our

ancestors during centuries• Division between cultures in

Engeland and the continent

In current risk assessments, the tsunami risk for the Netherlands is not taken into consideration, since a period of more than 7000 years is too long to be of any importance.

This method states to consider all assets and the risks regarding the assets. Unfortunately the organisation has to come up with all the risks itself. They can make use of prefabricated lists but still have to link these risks to their assets. In this light, the organisation and especially manage-ment, is never sure if they have found all risks and if the risks are sufficiently mitigated.

4.3. PCI DSS 2.0

Another method is the Payment Card Industries Data Security Standard. This standard has been developed by the PCI Security Standard Counsel (SSC). The SSC consist of five founding multi-national acceptance card brand members. Each brand develops and maintains its own PCI DSS compliance programs in accordance with its own security risk management policies. Pay-ment brand compliance programs handle compliance tracking, enforcement, definition of mer-



14 van 34

chants and service provider levels, and any penalties or fees that might be assigned. The brands are: ♦ American Express – Data security Operating Policy (DSOP); ♦ Discover Financial – Discover Information Security Compliance (DISC); ♦ JCB International – Data Security Program; ♦ MasterCard WorldWide – Site Data Protection (SDP); ♦ Visa, Inc. – Cardholder Information Security Program (CISP), Account Information Security

(AIS).

These standards are combined together to support PCI DSS compliance ♦ PCI PTS: Covers device tamper detection, cryptographic processes, and other mechanisms

used to protect the PIN; ♦ PCI PA-DSS: Covers secure payment applications to support PCI DSS compliance; ♦ PCI DSS: Covers security of the systems and networks that store, process, or transmit card

data.

The PCI DSS council is the governing body for maintaining the standards for the five credit card companies, such as PCI DSS and PTS. The council is responsible for keeping the documentation up to date, the distribution of the standard to its members and giving training to members and renewing the standard in a three year cycle.

An additional role of the council is defining and implementing validation requirements for Qualified Security Assessors (QSA), PA-QSAs and Approved Scanning Vendors (ASV). Asses-sors perform security assessments to ensure the compliancy of a company to the PCI require-ments to store, transmit or process cardholder data. The company which handles credit card data needs to perform an external vulnerability scan by an ASV quarterly, to ensure an independent and professional scan. The council publishes all approved members and companies on their website which enables an assessed company to check if their assessor is an approved member and if their vulnerability scan is done by an ASV.

The individual Brands have the following roles: ♦ Develop and enforce compliance programs; ♦ Fine or sanction for non-compliance; ♦ Endorse QSA, PA-DSS and ASV company qualification criteria; ♦ Accept validation documentation from approved QSA, PA-QSA, and ASV companies and

their employees; ♦ Provide feedback to the Council on QSA, PA-QSA, and ASV performance; ♦ Perform forensic investigations of account data compromise.

Defining the scoping of the environment is as follows: ♦ PCI DSS security requirements apply to all system components; ♦ System components are defined as any network component, server, or application that is

included in or connected to the cardholder data environment, including virtualization com-ponents;

♦ The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data.



15 van 34

The PCI DSS assessment consists of six goals and twelve requirements: ♦ Build and maintain a secure network

1. Install and maintain a firewall configuration to protect cardholder data; 2. Do not use vendor-supplied defaults for system passwords and other security parame-

ters; ♦ Protect Cardholder Data

3. Protect stored cardholder data; 4. Encrypt transmission of cardholder data across open, public networks;

♦ Maintain a vulnerability management program 5. Use and regularly update anti-virus software or programs; 6. Develop and maintain secure systems and applications;

♦ Implement strong access control measures 7. Restrict access to cardholder data by business need-to-know; 8. Assign a unique ID to each person with computer access; 9. Restrict physical access to cardholder data;

♦ Regularly monitor and test networks 10. Track and monitor all access to network resources and cardholder data; 11. Regularly test security systems and processes;

♦ Maintain an information security policy 12. Maintain a policy that addresses information security for all personnel.

PCI DSS defines the need for a risk assessment in requirement 12.1, establish, publish, main-tain, and disseminate a security policy that accomplishes the following: ♦ Addresses all PCI DSS requirements; ♦ Includes an annual process that identifies threats, and vulnerabilities, and results in a formal

risk assessment (examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30);

♦ Includes a review at least annually and updates when the environment changes.

Conclusion

The council does not define a specific method for risk assessment, but considers it an important part of the information security policy to indicate the possible threats and vulnerabilities. The scope of the PCI DSS framework is only cardholder data. The author has found that based upon several PCI Assessments the most risk methods follow the ISO 27001 way of thinking. The company performs a risk analysis, mitigates the high risks with controls. Next, look at the re-maining risk, is it worth investing or is it negligible? When new risks emerge, add them to the risk table and have management sign off. The author sees most requirements of this framework already derived from a basic risk analysis. Therefore a risk assessment does not add to the secu-rity of this framework and is only a tick in the box to become PCI DSS compliant.

A positive point of the framework is the mandatory vulnerability scanning on internally and ex-ternally faced servers. The use of mandatory scanning decreases the chance a hidden vulnerabil-ity for exploitation can be used. This control is additional to the required continuous checking for new security updates for all hardware or software used.



16 van 34

4.4. OWASP Secure Development

The Open Web Application Security Project (OWASP) Secure Development is subtitled as A Guide to Building Secure Web Applications and Web Services.

The OWASP is a worldwide not-for-profit charitable organisation focused on improving the security of software. Their mission is to make software security more visible, and by doing so enable individuals and organisations worldwide to make more fundamental decisions about true software security risks.


Vision OWASP

Everyone is free to participate in OWASP and all of their materials are available under a free and open software license. You'll find everything about OWASP on their wiki and current in-formation on the OWASP Blog. OWASP does not endorse or recommend commercial products or services which allow the community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. OWASP expects the community to look out for inappropriate uses of the OWASP brand including use of name, logos, project names and other trademark issues.

An OWASP project is a collection of related tasks that have a defined roadmap and team mem-bers. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team. Tools and documents are organized into the following categories: ♦ PROTECT - These are tools and documents that can be used to guard against security-

related design and implementation flaws; ♦ DETECT - These are tools and documents that can be used to find security-related design

and implementation flaws;



17 van 34

♦ LIFE CYCLE - These are tools and documents that can be used to add security-related ac-tivities into the Software Development Life Cycle (SDLC).

OWASP Secure Development is more a best practice for security professionals, security officers and programmers. The document places OWASP Secure Development in relation to other frameworks and best practices. It gives guidelines to secure coding, architecture and threat risk modelling.

Threat Modelling

When designing your application, it is essential you design using threat risk assessed controls, otherwise you will squander resources, time and money on useless controls and not enough on the real risks. The method you use to determine risk is not nearly as important as actually per-forming structured threat risk modelling. Microsoft notes that the single most important im-provement in their security improvement program was the universal adoption of threat model-ling. OWASP has chosen Microsoft’s threat modelling process as it works well for the unique challenges facing application security and is simple to learn and adopt by designers, developers, and code reviewers.

Threat Risk Modelling using the Microsoft Threat Modelling Process Threat modelling is an essential process for secure web application development. It allows organisations to determine the correct controls and produce effective counter measures within budget. For example, there is little point in adding a $100,000 control to a system that has negligible fraud risk.

There are five steps in the threat modelling process. Microsoft provides a threat modelling tool written in .NET to assist with tracking and displaying threat trees. You may find using this tool helpful for larger or long-lived projects.



18 van 34


Threat risk model

IdentySecurity

Objectives

DecomposeApplication

ApplicationOverview

IdentifyThreats

IdentifyVulnera-

bilities

The threat risk model starts with identifying security objects which are broken down to: ♦ Identification, the aspect of protecting the person’s identity against misuse; ♦ Reputation, the aspect of reputation damage; ♦ Financial, the financial loss; ♦ Privacy and regulatory, the protection of the user’s data; ♦ Availability, damage if availability is an issue.

Next step is the application overview. Expected is an analysis of the application regarding com-ponents, data flows and trust boundaries. We make a decomposition of the application to under-stand the architecture and setup. We determine which modules or aspects are critical, for exam-ple the authorization module. And we document and identify the threats and vulnerabilities. We use STRIDE and DREAD. STRIDE is the result of an attack, DREAD a form of impact analy-sis.

STRIDES are: ♦ Spoofing identity, to act as any other user, or becoming that user; ♦ Tampering with data, users can change any data delivered to them, and can thus change cli-

ent-side validation; ♦ Repudiation, users can dispute transactions if there is insufficient traceability and auditing

of user activity; ♦ Information disclosure, users are wary of submitting private details to a system, an attacker

can reveal user details; ♦ Denial of Service, an applications should be aware of being abused by a denial of service

attack;



19 van 34

♦ Elevation of privilege, if an application provides user and administration roles, it is vital to ensure that the user cannot elevate themselves to any higher privilege roles.

We give the rating in DREAD, as a risk value.

RiskDREAD = (DAMAGE + REPRODUCABILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

This produces a number between 0 and 10. The higher the number, the more serious the risk. ♦ Damage potential, if a threat is realized, how much damage is caused?

• 0 = nothing; • 5 = individual user data is compromised or affected; • 10 = complete system down.

♦ Reproducibility, how easy is it to reproduce this threat? • 0 = very hard or impossible, even for administrators of the application; • 5 = one or two steps required, may need to be an authorized user; • 10 = requires just a browser address bar without being logged on.

♦ Exploitability, what do you need to have to exploit this threat? • 0 = advanced programming and networking skills, advanced or custom attack tools; • 5 = malware exists, or easily performed using normal attack tools; • 10 = just a browser.

♦ Affected Users, how many users will this threat affect? • 0 = none; • 5 = some users, but not all; • 10 = all users.

♦ Discoverability, how easy is it to discover this threat? When performing a code review of an existing application, “Discoverability” is usually set to 10 as it has to be assumed that these issues will be discovered. • 0 = Very hard to impossible. Requires source or system access; • 5 = Could figure it out from guessing or watching network traces; • 9 = Details of faults like this are in the public domain, and can be discovered using

Google; • 10 = It’s in the address bar or in a form.

Conclusion

The Threat Risk model is designed for risk analysis of application development only. Specifi-cally the secure design and the impact an insecure application has on an organisation. Risks are found in the current use of cyber attacks and knowledge of hacker communities. The author knows this knowledge of OWASP is not a widespread as it should be. The advantage of using OWASP is security awareness amongst application developers, especially web faced applica-tions. Through awareness, better programs are made with fewer vulnerabilities. Downside of this method is to isolate software development, although infrastructure must be seen as a whole. Information security is more than software development, server hardening etc. It needs a layered approach. A risk method must consider a layered approach. If we regard a default company with



20 van 34

a website in a DMZ, as depicted below: The company uses an external and internal firewall, so that layer is secure. An entry to the internal company LAN could be via the website company.


Web portals

Internalfirewall

Externalfirewall

Hacker

Demilitarized Zone(DMZ)

LAN

Internet

Website Company

The development of the website is outsourced to a software company. This software company does not develop with OWASP in mind, which causes that vulnerabilities are available for hackers to exploit. If the company would use an active security patch policy the exploit of the website would not automatically lead to a security breach. The risk management of the company must regard all traffic from the website as a high risk and use additional mitigating measures.

4.5. NIST SP 800-30 Risk Management Guide for Information Technology Systems

Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organisation.

In order to determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system. Impact refers to the magnitude of harm that could be caused by a threat’s exercise of vulnerability. The level of impact is governed by the potential mission impacts and in turn pro-duces a relative value for the IT assets and resources affected (e.g., the criticality and sensitivity of the IT system components and data).



21 van 34


NIST 800-30

Step 1. System Characterization

Step 2. Threat Identification

Step 5. Likelihood Determination

Step 3. Vulnerability Identification

Step 4. Control Analysis

Step 6. Impact Analysis (Loss of CIAA)

Step 9. Results Documentation

Step 8. Control Recommendations

Step 7. Risk Determination

Operating system

• Information• Software

Application

Network

• Scope• Highest value

Relevant threats

Expected damage: net risk

Residual risks

Additional controls

Relevant vulnerabilities

i=1ΣN Likelihoodi x Impacti

C = ConfidentialityI = IntegrityA = AvailabilityA = Audit ability

The risk assessment methodology encompasses nine primary steps, which are: ♦ Step 1 System Characterization, defining the scope; ♦ Step 2 Threat Identification, a threat is the potential for a particular threat-source to success-

fully exercise a particular vulnerability; ♦ Step 3 Vulnerability Identification, develop a list of system vulnerabilities (flaws or weak-

nesses) that could be exploited by the potential threat-sources; ♦ Step 4 Control Analysis, analyze the controls that have been implemented or are planned for

implementation by the organisation to minimize or eliminate the likelihood (or probability) of a threat exercising a system vulnerability;

♦ Step 5 Likelihood Determination, the likelihood that a potential vulnerability could be exer-cised by a given threat-source can be described as high, medium, or low;

♦ Step 6 Impact Analysis, to determine the adverse impact resulting from a successful threat exercise of a vulnerability. Impact per loss of integrity, availability and confidentiality;

♦ Step 7 Risk Determination, to assess the level of risk to the IT system. The assessment per likelihood, magnitude and adequacy of planned or existing security controls;

♦ Step 8 Control Recommendations, controls that could mitigate or eliminate the identified risks, as appropriate to the organisation’s operations, are provided. The goal of the recom-mended controls is to reduce the level of risk to the IT system and its data to an acceptable level;

♦ Step 9 Results Documentation, the results should be documented in an official report or briefing.



22 van 34

Conclusion

The NIST method devotes more attention to the “vulnerabilities”. The author sees this as the flaw in this method since only known vulnerabilities are addressed. The users of this method can easily enough find a list of known vulnerabilities, URLs with lists or organisations where more information can be found. This can be used to analyse the organisation. Even though pre-defined lists are available, this method only provides ways to perform a risk analysis. The author states that not all vulnerabilities are identified new vulnerabilities may arise and that with a static once a year risk analysis no better security against an attack can be expected. As example the Bring Your Own Device can be used. More and more people take all kinds of equipment from home to work. Mostly these are consumer-oriented devices, such as smartphones, tablets and netbooks. This trend is called Consumerization, or Bring Your Own Device (BYOD). Con-sumerization means that at home and at work the same mobile equipment is used, and that peo-ple may use their own equipment at workplace.


Bring Your Own Device

CompanyNetwork

The increasing mobility challenges organisations and the IT department. They need to think dif-ferently about the provisioning of computer services, ensuring good security and controlling the use of technology. The need to mitigate the risks must be balanced against the need of mobile workers to have freedom of choice and personal control over their computing environment.

Mobility increases the risks, which makes protecting sensitive data difficult. Although applica-tions and data are the safest inside the properly shielded corporate domain, they often have to be made available for use offline, without connection. A first step is the identification of the rele-vant risks of unauthorized disclosure of information.



23 van 34

Another aspect of BYOD is the unknown number of vulnerabilities which have been encoun-tered recently. On the android app market, the Google Playstore, Google is trying to remove apps from the store which contain malware18. Another vulnerability is the way the mobile de-vices are used. These devices have been developed with home users in mind. When these users take the devices with them to work the possibility exists that new vulnerabilities to the internal network are introduced, e.g. viruses, malware and other unwanted programs.

This risk method is too complex to execute more than once or twice a year. Vulnerabilities are unpredictable and turn up more frequently than formerly estimated.

5. Are all possible risks found regarding vulnerabilities and possible threats?

5.1. Risks are unknown

The classical approach to risk analysis remains valuable. One must keep looking to the past in order to predict what may happen in the future, since history repeats itself. In the opinion of the authors, risk is far too limited and attracts too little real enthusiasm. Some practical constraints, as described by Beusenberg and Fasten in their essay “Elusive chain risks for financial institu-tions”19 are: 1. An auditor or IT auditor is given a budget to match an object. There is hardly any room to

watch the end-to-end risk from the chains and the parent processes. He or she is restricted to the scope of the contract and forced to remain within the rules prescribed by it;

2. An organisation may be aware of its vulnerabilities. But it is human tendency to talk as little as possible about vulnerabilities and sometimes not even think about them. Many people are naturally optimistic, and believe “we will probably not face that problem” or “this will be the last time it happened.” This corresponds to what the NIST defines as the standard 800-30 extra attention to the known vulnerabilities;

3. Many people have little imagination. They adhere strictly to the standard lists of threats and to what they traditionally do. They are not open for signals from either society or science about new threats and risks. Either they do not see these signs at all, or they do not pay heed to the pressing need for changing their approach;

4. Sometimes information about threats is kept secret or is not shared because nobody wants to have it known they had a break in. For example, many banks are closed on the issue of Cy-bercrime and their approaches to overcome them20. Intelligence is also closed on trends they find by research. As a result, auditors and risk managers do not always receive the right sig-nals they need as input for their audits and risk assessments;

5. Cybercrime remains something that sounds “high tech”. However, there is a considerable lack in the number of technical IT auditors. Many organisations face the reality of “too much need for technical audits and far too few technical auditors available”. The auditors therefore miss the necessary assistance that they need to properly estimate cyber risks.

18 http://www.security.nl/artikel/43488/1/Google_gaat_Android-apps_op_malware_scannen.html. 19 C.N.A. Beusenberg and J.E. Fasten, “Elusive chain risks for financial institutions”, thesis VU PBL IT Audit, on www.vurore.nl, April 2010. 20 A. Wouda, “The control of cyber crime in Dutch small banks”, The IT Auditor, 2011, issue 4, pp. 22-28, based on a thesis VU PBL IT Audit.

http://www.security.nl/artikel/43488/1/Google_gaat_Android-apps_op_malware_scannen.html



24 van 34

In short, there is often a narrow-minded approach towards risks that are already known from the “past”. Moreover, the “now” is neglected or ignored, while the risks of the “future” are often ignored. There are in fact enough signals, but the question is how appropriately do enthusiasts respond to them? Will they have enough time and resources for the real risk mapping and can they thus contribute to a safer society? The answer is actually: “no”.

5.2. Risks are systematically overlooked

Acknowledging risks requires understanding and analysis of what can go wrong. Let us consider some recent incidents where the risks were in fact known on the basis of available signals, espe-cially those cases where the directly involved have solved the incident in time.

Stuxnet is an almost perfect cyber weapon that has caused substantial damage as part of the modern electronic warfare21.


Stuxnet: Command flow (Symantec)

Stuxnet took advantage of vulnerabilities in process automation, which were already described by Nieuwenhuis and Peerlkamp22 among others. Worryingly however is that the concept is “public” and can also be used for other attacks. It is currently known that the concept of Stuxnet is modified to fit on other infrastructure which can be used by various parties (including crimi-

21 Symantec Security Response, “W32.Duqu: the precursor to the next Stuxnet”, version 1.4, November 23, 2011. 22 M. Nieuwenhuis and S. Peerlkamp, “Process Control Network Security, Comparing frameworks to miti-gate specific threats to the Process Control Networks”, thesis VU PBL IT Audit, on www.vurore.nl, March 2010.



25 van 34

nals?). It is now important for organisations to take action against a prospective Stuxnet-like attack on its infrastructure.

Duqu is a relatively little-known variant of Stuxnet, focused on cyber espionage and gathering information in order to attack.


Duqu: Data flow (Symantec)

Your computer

A part of Duqu is so advanced that in March 2012, Kaspersky Labs asked for help from the hacker community to understand the programming technique23. The impression arises that Stux-net and Duqu have been developed by parties who have extensive knowledge and vast re-sources, because these advanced cyber weapons seem totally unlike what usually comes from the hacker community.

While developing the OV-chips, the weaknesses and vulnerabilities of the Myfare Classic chip became public, as described by Niemantsverdriet24. The consulted experts were initially con-vinced that, given the limited value of transactions, the risks were manageable. Scientific groups are now debating about this wrong perception of reality. The present risks are more prominent than was expected by the experts. Nowadays there is a more secure chip, but how long will this stand against the foreseen attacks? It is known that “security by obscurity” in the long term will always fail.

23 Computable, “Kaspersky asks for help in fighting Duqu”, March 8, 2012. 24 P. Niemantsverdriet, “The decision-making around the development and implementation of the OV-chip card, a success or failure”, thesis VU PBL IT Audit, on www.vurore.nl, May 2011.



26 van 34

Despite carefully conducted risk assessments, insufficient measures were taken and many or-ganisations are still affected by these incidents. Taleb25 argues in his book “The Black Swan” that one must also take into account the highly improbable. Recent history teaches that there is always something happening that was considered extremely unlikely, but still has a substantial impact on our modern society. And so is the case with our modern IT infrastructure.

Conclusion

Are all possible risks found regarding vulnerabilities and possible threats? The risks are un-known or systematically overlooked. The risks are unknown due to unawareness or a simple approach on risk inventory. The risks are often overlooked because the risks involved are very small and the strong feeling of security by obscurity. Therefore we must conclude that not all possible risks are found.

6. And how can a risk framework decrease the vulnerabilities and possible threats of the IT infrastructure?

We have the problem of unauthorized or unforeseen risks that needs to be addressed. This is only possible with the power and status of the highest body within the organisation, including the Board, a Board of Directors, a Secretary General, etc. Their job is governance of the organi-sation in such a way that it achieves its goals “with careful consideration of the risks”. Ironi-cally, often such evaluation of risks, comprises a ‘good-to-act’ option rather than a ‘must act’ because of their busy calendars. Many items, as a result, remain pending. These include: Much needed decisions within the strategic or tactical agenda on the view of the organisation regard-ing BYOD, Wireless, The New Way of Working (e.g. from home or at a customer), social me-dia, apps on iOS or Android, the upgrade to another platform, implementing business continuity, and other developments that may affect the relationship between business and IT services.

So, there is need for a separate function in the immediate vicinity of the senior management whose primary role would be to focus on information about how to evaluate, combine and report risks. Traditionally, this was the position of a Chief Risk Officer. Given the increasing impor-tance of information within information-intensive organisations however, the functionality could be raised to the position of a Chief Information Security Officer, the CISO. Many multina-tional companies and large organisations have already introduced this role, usually at a high level, in order to give sufficient weight to this position.

A CISO has a strong mandate that consists of required competencies and tools plus sufficient funds. Besides the above classical tools such as ISO 27001, NIST 800-30, etc., there is a clear need for agents whose responsibility is to identify and bring unrecognized and unanticipated risks to the attention of the leadership. In the context of the argument, these include the e-Competence Centre, continuous risk monitoring, the Risk Register and intelligence. These top-ics are discussed below.

25 N.N. Taleb, “The Black Swan, the Impact of the Highly Improbable”, Harvill Press, ISBN 978 90 5712 2675, 7th printing, 2010.



27 van 34

6.1. e-Competence Centre

A further analysis of the above mentioned incidents shows that most of them were not entirely unexpected. The threat was in fact known but it was the impact itself that was surprising. Nieu-wenhuis and Peerlkamp, graduates of the VU Post Graduate IT Audit Training and winners of the Joop Bautz Information Security Award 2010, have published a paper in 2010 about the vul-nerability of the process. They put together existing knowledge to show that the process is insuf-ficiently protected and increasingly vulnerable to external threats (which was later proved by the launch of Duqu and Stuxnet. Interestingly, the thesis was submitted in March 2010, while Stux-net was discovered on 13 July 2010. This shows that the vulnerabilities were already known.

Taleb completely surprised us with the amazing effect of using the analogy of the black swan, which is not only rare or strange, but also outside our narrow field of view of possible events. He argues that it is not impossible to fathom the cause and possible consequences for rare events. While it is not possible to calculate the exact probability, one can at least form an image of a threat with a very small probability of occurrence, but with a huge impact. By thinking in advance about black swans and considering them, while making assessments for the design of systems of measures, one can minimize the surprise element of the black swans and even the grey swans. So, for example, this means that the Japanese could have known that the Fukushima switchboard for emergency generators in the turbine building was at a vulnerable spot, namely underwater, and would face great disaster if a super-tsunami should strike. If the correct value of the threat had been anticipated and was included in the reasoning, the construction of emergency generators could have been planned higher up, say on a hill, and even the switch panel might have been moved.


Incidents

Fraud, abuse

Vulnerabilities

Threats

e-Competence Center and robustness

e-Competence CenterThink tank

Strategists

Outside the boxthinking

Tactical view

Operational

Cost-conscious

ArchitectsEngineers

Risk staffSecurity staff

Proactivesecurityview fore and IT

e-threats, IT threats and vulnerabilities

CISO

EmergencyResponse

Team

Risk Register

SHARE



28 van 34

In the context of this thesis about the framework as a basis for a more cyber related risk ap-proach, the author pleads for the deployment of a think tank, in fact, a group of experts who will remain focused on intelligence. Their task could be collecting information about incidents, vul-nerabilities and threats. Much of this information is now easy to collect via the Internet. Em-ployees in the think tank should have imagination and must be ready to ask the “what if?” ques-tion. Or more in the line of Taleb’s way of thinking, they need to be aware of the Black Swan. It may be a risk coordinator within our Dutch Delta Works who can ask the question “what can happen if our process computers are targeted?” Or, perhaps, more specifically, “what happens if a virus is focused on our process computers?” This follows the logic of how the protection of the process computer is similar to the protection that floodgates of a dam needs. The answer is perhaps that more than a single firewall is needed in the corresponding LAN, better intrusion detection or other signalling capabilities are needed, and the process software on the computer is more often checked for unauthorized modification. This leads to the conclusion that a Stuxnet-like attack on the locks and dams of Delta works could lead to a serious incident. A cheap solu-tion is to disconnect the process computers from the LAN of other networks and rely on the former system of physical isolation of networks with different security requirements26. A disad-vantage here is that the central control of the processing computers is more complicated. It is less user-friendly, but safer. An alternative is having more strict controls around the computer and infrastructure assuring that the auditor checks the chain of controls and the overall security policy more frequently.

The think tank is an e-Competence Centre, and a hub of experts from different disciplines. Ei-ther way a participation of technical experts for the platforms, middleware and applications, plus web specialists who are involved in the OWASP measures is needed. They focus on the technical threats and vulnerabilities within their specific competencies. In addition, there are risk experts from the participating business units who take a wider look at threats from the out-side world, as well as criminal and political developments among other things. Together they have the knowledge and skills to counter threats as per their importance. They do this partly by linear reasoning and partly by “thinking outside the box”. What is important is that there is some creativity in the process combined with the thematic control.

The e-Competence Centres report to the Chief Information Security Officers (CISOs) of their respective organisations. This way, the link is made with senior management, to provide suffi-cient priority on the results of their work.

26 U.S. Department of Defense, “Trusted Computer System Evaluation Criteria”, CSC-STD-001-83, Au-gust 15, 1983, replaced by STD DoD 5200.28-STD, December 1985.



29 van 34

6.2. Risk Register


IT-audit supporting the CISO, interacting with e-Competence Center

e-Competence Center CISO

Scenarios

Audit planSpecific audits

The Board

IT-auditor

• Act as profiler• Assess robustness and framework• Signal weaknessess

Known threats

Known vulnerabilities

Black swans

Superior e-Competence Center

e-CompetenceCenter ofBusiness partner

Risk Register

Organisations often make insufficient use of historical risk information. User organisations and IT departments increasingly analyze threats, assess their impact and likelihood of occurrence and (re) assess the system of risk-mitigating measures in such a way that it can be applied when necessary. This usually happens often within projects in the context of change management. This information is then kept in so-called “Risk Registers” for the project and is actively man-aged by the project team. After that, however, much knowledge is lost in the process of reor-ganisation, especially when staff is being replaced. Loss of historical knowledge is a handicap for a careful risk assessment since a view over a longer period of time becomes almost impossi-ble.

Individual Risk Registers are rarely brought together and managed to provide overview continu-ity. A unified, historically complete, and constantly updated Risk Register is a great tool for an e-Competence Centre. This register includes all information that various parties have collected about risks and vulnerabilities which enables them and others to see what measures have already been taken. By doing so, the focus can be put on assessing the effectiveness of these measures in order to detect possible flaws in the system.

In the context of this thesis, we make a case for the central collection of local and locally avail-able information on threats and vulnerabilities. This requires setting up a network of risk coor-dinators at a low level within organisations. This network will monitor and provide information to a central body. The information will be recorded in the central Risk Register, and thus, made available to the e-Competence Centre.



30 van 34

The Risk Register may include input for the test sets for new software and new systems. If we approach this, and combine them with the DTAP and OWASP testing, we can substantially im-prove the robustness of information systems and web applications.

6.3. Intelligence collection and use

How does Taleb turn a black swan into grey? He warns that whatever one does, there always remain some unsuspected black swans. In fact as soon we start talking about the possibility of a black swan it may no longer remain black. The challenge is to provide, with the advent of a black swan, an intelligent and scientific approach. Depending on the market, threats can be di-vided into categories and information can be selected and sorted. This will be realised within the e-Competence Centre, individually and group wise, so as to maximize the skills and to ensure that that new creative insights flow in.

For threats with a very large impact and a very small chance of occurrence, one uses the princi-ple of grey from “The Black Swan”. This means that the main possible causes and consequences of framing will be considered. This includes the possible scenarios that have been arrived at by reasoning. These possible scenarios determine where redundancy exists within the business, IT facilities etc., and determining whether this redundancy will be sufficient. It should be a the-matic approach. First, this analysis focuses on platforms and technologies, such as databases, hardening of the server, and secure web applications and business logic. Second, the analysis focuses on the various categories of threats.

One of the possible methods is the intelligence-like performance of linkage analysis, such as that described by Labuschagne27. Here the conditions include, apart from the modus operandi, the population of potential attackers. With the mode of operation, the operations refer to the ac-tions used for performing a break-in, or causing damage by an offender. The perpetrator has a purpose, namely to ensure that the intrusion is damaging, hiding his or her identification, and obtaining funds or opportunities to steal information. The modus operandi in successive actions may change because the attacker will improve and learn better techniques. It is possible for the information security to catch the perpetrator who is imprudent by using certain known tech-niques. The “signature” of an offender can be those actions, which though unnecessary for the actual act of the crime, serve to satisfy the psychological needs of the offender if he wants to show off and outrun than the security experts. This way of operating can become part of the modus operandi.

This kind of analysis is in line with the approach of detection by police and the work of intelli-gence and security. And therefore such an approach has an increasingly strong relationship with the cyber world. As described by Berg28, people are wrestling to find a responsible balance be-tween the efficiency of the detection task, the tactical importance of the investigations, and the privacy interests of those involved.

27 G.N. Labuschagne, “The use of a linkage analysis as evidence in the conviction of the Newcastle serial murderer, South Africa” in Journal of Investigative Psychology and Offender Profiling, Vol. 3, Nr. 3, pp. 183-191, October 2006. 28 B. Berg, “Criminal Investigation”, Edition 4, McGraw-Hill, ISBN 978-0073401249, 2007.



31 van 34

7. Conclusion

We have researched the following main question: “How can we decrease the risks of vulner-abilities and possible threats to the company IT-infrastructure which also meets the current and future demands of a complex web based application environment?”

We have done the research via the following sub questions: ♦ What is the scope of the risk framework? ♦ What risk methods are currently available? ♦ Are all possible risks found regarding vulnerabilities and possible threats? ♦ And how can a risk framework decrease the possible threats and vulnerabilities of the IT

infrastructure?

The scope of risk framework is the future based (or forward looking) risk.

The researched methods show that the current way of risk thinking is historical based and not complete. In some methods the focus is on management involvement, others are more threat or vulnerabilities based. None of the methods keeps track of all risks that are found. A central way of organizing threats, vulnerabilities is not available. Every organisation is searching for guid-ance and often “reinvents the wheel”. The method is only a tool for risk awareness, not for set-ting up a framework which continuously keeps track of risks and potentially shifting of risk when organisations change. Methods are available, but not as effective as they should be.

Are all possible risks found regarding vulnerabilities and possible threats? Risks are shifting. Security by obscurity is no longer an accepted means of security. Risks registers only consist of the default lists found on the Internet and not from a business point of view. New threats and new vulnerabilities are constantly emerging. Who would have thought five years ago we would bring our own iPad or other tablet to work and be able to gain access to sensitive corporate in-formation this way? Or using your phone attached to the laptop as an unsecure network access point with no firewall or other means to secure the network access from the Internet. We can state that not all risks are found.

And how can a risk framework decrease the possible threats and vulnerabilities of the IT infra-structure? The answer is two-fold. The use of an e-Competence Centre which searches for new threats and vulnerabilities and the use of a risk register which documents all found information and makes it widely available. This way all participants combine their knowledge and gain the fruits of the combined efforts. This is a continuous effort since risks will shift constantly. An example is when a data centre is planning an extension to the building. In different stages, the risks will shift. For instance, when the wall between the new part and the old part is demolished, people are temporarily able to enter the data centre without proper authorization. Therefore con-tinuous scans are necessary for cyber attacks as well as operational changes.

The overall conclusion for the research problem: “How can we decrease the risks of vulnerabili-ties and possible threats to the company IT-infrastructure which also meets the current and fu-ture demands of a complex web based application environment?” is to let the organisations ap-pointed CISO use the combined knowledge of experts via a new organisation that is yet to be created called e-Competence Centre and a Risk Register. The knowledge in a Risk Register can



32 van 34

be used within the company for all departments to use. The Risk Manager can review the cur-rent risk assessment and see if all risks are still valid or if change of the risk level is needed. The engineers can check if their software or hardware needs a security patch etc. We can decrease the risks, but can never be 100% secure.

8. Self reflection

The process from research question to finished thesis was difficult. The initial research question was not specific enough and I elaborated in detail on the question. During my discussion about the research question with Marco van der Vet, Risk Manager Capgemini and Willem Barnhoorn, Security Manager Capgemini, the direction went more towards the forward risk ap-proach and response teams. The current threads and vulnerabilities found daily are presenting new risks. The approach of creating a framework changed in a question related to protect the application and data by a continuous risk approach. Performing a risk analysis once a year e.g. for ISO 27001 compliancy, is insufficient. This resulted in a better question to research. The sub questions have also been made more specific to research the current risk methods within current frameworks. During the process I have discussed the topic with colleagues, security and other IT professionals to obtain their view and include them in the thesis. To provide examples to em-phasize the need for such a framework was not a problem. In the media more than enough vul-nerabilities and threats were addressed to provide a basis for my research.



33 van 34

Literature 1. J.R. Prins, “Diginotar Certificate Authority breach Operation Black Tulip”, version 1.0 5

September 2011, Publisher: Fox-IT; 2. http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar; 3. http://nl.wikipedia.org/wiki/Man-in-the-middle-aanval; 4. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project; 5. http://www.security.nl/artikel/39679/1/Top_10_grootste_SQL-Injection_datalekken.html; 6. http://en.wikipedia.org/wiki/Sql_injection; 7. http://www.security.nl/artikel/39711/1/120.000_Nederlandse_pagina%27s_gehackt_tijdens

_aanval.html; 8. Bokkerink, Dutch National Cyber Security Strategy, First edition 22-02-2012; 9. http://www.security.nl/artikel/43502/1/3-

jarige_hackt_website_via_SQL_Injection_%28video%29.html; 10. http://en.wikipedia.org/wiki/Web_portal; 11. http://www.security.nl/artikel/43268/1/Nieuwe_Dorifel_verspreidt_BumaStema-virus.html; 12. http://www.security.nl/artikel/43301/1/Zero-day_lekken_89_dagen_misbruik_in_IE.html; 13. International Standard ISO/IEC 27001:2005(E), First edition 15-10-2005, Publisher: ISO; 14. PCI Council, PCI Data Security Standard, Requirements and Security Assessment proce-

dures version 2.0, October 2010, Publisher: PCI security council LLC; 15. Marc Curphy et al, A guide to building secure web applications and web services, second

black hat edition July 2005, Publisher: The Open Web Application Security Project; 16. Gary Stoneburner, Alice Goguen and Alexis Feringa, “Risk Management Guide for Infor-

mation Technology Systems SP800-30”, July 2002. Publisher: National Institute of Standars and Technology (NIST);

17. OECD Guidelines for the Security of Information Systems and Networks – Towards a Cul-ture of Security. Paris: OECD, July 2002. www.oecd.org;

18. http://www.security.nl/artikel/43488/1/Google_gaat_Android-apps_op_malware_scannen.html;

19. C.N.A. Beusenberg and J.E. Fasten, “Elusive chain risks for financial institutions”, thesis VU PBL IT Audit, on www.vurore.nl, April 2010;

20. A. Wouda, “The control of cyber crime in Dutch” small “banks”, The IT Auditor, 2011, is-sue 4, pp. 22-28, based on a thesis VU PBL IT Audit;

21. Symantec Security Response, “W32.Duqu: the precursor to the next Stuxnet”, version 1.4, November 23, 2011;

22. M. Nieuwenhuis and S. Peerlkamp, “Process Control Network Security, Comparing frame-works to mitigate specific threats to the Process Control Networks”, thesis VU PBL IT Au-dit, on www.vurore.nl, March 2010;

23. Computable, “Kaspersky asks for help in fighting Duqu”, March 8, 2012; 24. P. Niemantsverdriet, “The decision-making around the development and implementation of

the OV-chip card, a success or failure”, thesis VU PBL IT Audit, on www.vurore.nl, May 2011;

25. N.N. Taleb, “The Black Swan, the Impact of the Highly Improbable”, Harvill Press, ISBN 978 90 5712 2675, 7th printing, 2010;

26. U.S. Department of Defense, “Trusted Computer System Evaluation Criteria”, CSC-STD-001-83, August 15, 1983, replaced by STD DoD 5200.28-STD, December 1985;

http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar

http://nl.wikipedia.org/wiki/Man-in-the-middle-aanval

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.security.nl/artikel/39679/1/Top_10_grootste_SQL-Injection_datalekken.html

http://en.wikipedia.org/wiki/Sql_injection





http://en.wikipedia.org/wiki/Web_portal

http://www.security.nl/artikel/43268/1/Nieuwe_Dorifel_verspreidt_BumaStema-virus.html

http://www.security.nl/artikel/43301/1/Zero-day_lekken_89_dagen_misbruik_in_IE.html

http://www.oecd.org/





34 van 34

27. G.N. Labuschagne, “The use of a linkage analysis as evidence in the conviction of the New-castle serial murderer, South Africa” in Journal of Investigative Psychology and Offender Profiling, Vol. 3, Nr. 3, pp. 183-191, October 2006;

28. B. Berg, “Criminal Investigation”, Edition 4, McGraw-Hill, ISBN 978-0073401249, 2007.

Documents

Application and Data Security Framework...An example is the security breach at Digi-notar Certificate Authority, as described in the report “Diginotar Certificate Authority breach