Taking a different approach on securing application

Introduction

Heartbleed, Shellshock and Poodle. These are some of the highly talked vulnerabilities for the year 2014. We live in an Internet era where they can never be a day without vulnerabilities not being found or an organization not being compromised. Things seem to get worse when such vulnerabilities are used as a form of weapon geared towards critical infrastructure. As defined by Wikipedia; critical infrastructures are assets that are essential to the functioning of the country's economy and society [1]. If an attack towards our critical infrastructure were to happen and worse, succeed, then it will definitely impact the country, from the savings in our banks, transportation on the roads to the distributing of gas, water and electric to our everyday needs.

This blog intends to share the problems with majority of the critical organizations systems, the reports in the news, the challenges faced towards software developers and how by introducing a process called S3VLC can help protect critical organizations.

Attacks on Critical Infrastructure

On November 18th 2011, reports state that a group of foreign hackers were targeting U.S water plants. It was said to be the first known cyber-attack that damaged the water and electricity distribution systems [2]. On June 30th

2014, Symantec uncovered a malware campaign from a group called Dragonfly which compromised more than a thousand power plant systems[3]. On April 4th 2012, according to DHS, the America's water and energy utilities face daily cyber espionage and DOS attacks against its industrial control systems [4].

Problems in Software Security

These cyber-attacks are not surprising especially when vulnerabilities are constantly found on these critical infrastructure systems. On October 18th 2013, researchers in the US found over 25 security vulnerabilities in SCADA systems [5]. On September 18th 2014, 3 security holes were found in the commonly used SCADA software from Schneider Electric [6]. And through these vulnerabilities, according to Darlene Storm, a security blogger for Computerworld, hackers took advantage of these holes to take full control of critical infrastructure [7].

"On average over 70% of IT Security budget is spent on Infrastructure, yet over 75% of attacks happen at the Application level." - Rob Labbe (Microsoft SDLC for IT)

SDLC

SDLC or Software Development Life Cycle is a process for planning, creating, testing and deploying an information system. In SDLC, security has never been part of the process thus making the application stable but insecure. Recent article from The Register states that 80% of application developers suck at securing client's data [8]. This is not a surprise since majority of application developers are good at that - developing applications and nothing else hence security is never part of the process. The introduction of adding security as part of the SDLC process is slowly being adopted by application developers and software making companies however due to constraints in time, tools and budget, little of the security portion are deployed in the process [9].

Secure Source Code Review

One of the earliest starting point for a SSDLC is the introduction of secure source code review. Using manual or automatic approach and analysis tools, code reviewers analyse source code in order to help find security flaws. This stage allow reviewers to find issues such as buffer overflows, SQL injection flaws and cross site scripting. All these can be tackled before final compilation.

Challenges

There are a number of challenges in this stage. One is time constraint and by taking a manual approach, it is extremely difficult to look through the thousands or even million lines of codes. And if an automatic approach is adopted using tools, then chances of false positives are high and many potential vulnerabilities such as authentication problems, access control issues are hard to get flagged.

Transparency of SSDLC

Some of the biggest challenges to clients when purchasing the SCADA software is the inability to know the contents of the software and has no transparency to whether proper SSDLC process being adopted during its development. To add to this woes, many critical organizations using SCADA application have little or no security team in place to ensure the ‘cleanliness’ of the software and have little or no expertise to test the reliability of security of the software.

Without proper security verification check, engineers and operators risk themselves by installing the software in their production environment, thus allowing potential known and unknown vulnerabilities lurking in their environment waiting to be exposed or exploited.

Another challenge is that clients usually are not provided with the source code of the application from their vendors due to many reasons and one of them is the potential leakage of their source code to competitors or online.

Current Vendor to Client Cycle

Fig 1: Vendor-Client cycle

S3VLC

S3VLC or SCADA Software Security Verification Life Cycle is a process that would allow organizations to test and check the security of their applications, adopting the art of binary analysis and fuzzing. This framework allow organizations not to rely or depend on the software vendors and instead taking ownership of the software and ensuring its security before deploying to their environment.

Binary Analysis

Binary analysis is the process of analysing the binary code to search for compliance issues and vulnerabilities in 3rd party libraries. The idea behind this assessment is to think what could a hacker possibly do or find out about the compiled executable. Unlike code review, binary analysis do not rely on assumptions but instead it will detect on the actual libraries and components in the binary and check the version of the libraries and with these versions known and detected, give references to vulnerability databases such as CVEs or NVDs and see if any components are vulnerable. This process allows client to have the transparency in the BOM (Bill of Materials) to the software and gives the ability for the clients to manage any vulnerabilities found and understand its potential risks if such software are deployed.

Fig 2: List of Third Party Components and the Vulnerabilities associated with it

Fuzzing

Fuzzing is a technique used by introducing malformed or random data to an application and see the output of it that may reveal potential security issues. In 2006, according to an article from The Register, security researcher HD Moore managed to find a number of bugs in the Internet Explorer browser using the fuzzing technique [10]. In a presentation by John Neystadt, a Microsoft employee states that 'over 70% of security vulnerabilities Microsoft patched in 2006 were found by fuzzing [11]. Thus, as fuzzing becomes increasingly important as a way to find potential bugs and zero days, Microsoft security guru, Michael Howard stated back in 2007 to adopt fuzzing as part of the software creation process [12]. And when Microsoft starts to adopt fuzzing as part of its process, in 2010, the company found over 1800 Office bugs [13]. This shows that by incorporating fuzzing technique as part of a security life cycle framework, is beneficial to the software owner and users.

An example of how easy it is to perform a Denial of Service attack via fuzzing technique:

Fig 3: Illustration on how an application is fuzzed

Fig 4: Application crashed due to unable to understand packets received

The S3VLC Framework

Fig 5: S3VLC in action

The Future of Software Security through Transparency

Last year, Dec 4th, U.S. representatives introduced "Cyber Supply Chain Management and Transparency Act of 2014." The legislation will ensure all contractors of software, firmware or products to the federal government provide the procuring agency with a bill of materials of all third party and open source components used, and demonstrate that those component versions have no known vulnerabilities. [17]

Fig 6: The Bill at glance

This act enforces vendors providing firmware, software and hardware to the U.S. government to provide the BOM (Bill of Materials) of the F/S/H and to demonstrate that components used are not vulnerable and software must be created for patching as well.

Conclusion

The main idea for this framework is to allow organizations to properly validate and evaluate the software using the art of binary analysis and fuzzing technique. As consumers are not given with the source code as well as the transparency to know whether or not vendors adopt proper SSDLC approach in creating the software, S3VLC framework allow organizations to find both known and unknown vulnerabilities in the software they purchased/evaluate thus allowing them to work closely with the vendors to improve and minimize the potential risks involved based on the results found.

Final Words

There can never be a silver bullet when it comes to protecting the infrastructure. We have evolved to a generation where having an Antivirus and firewall is just a small piece of a bigger puzzle that needs to be filled. The list to secure an environment is exhaustive, ranging from SSDLC, OS hardening, network security perimeter for both internal and external, audit and compliance, following best practices when it comes to network design to the implementation of event logging and network monitoring. As the famous phrase 'Security is a Journey, Not a Destination', there can never be a one solution that solves everything. As security professionals, it is our duty to educate the masses about the importance of security and the consequences of ignorance. And as an end user, it is our duty to understand that security is a shared responsibility and that we all have a role to play in it.

References

[1] http://en.wikipedia.org/wiki/Critical_infrastructure

[2] http://www.washingtonpost.com/blogs/checkpoint-washington/post/foreign-hackers-broke-into-illinois-water-plant-control-system-industry-expert-says/2011/11/18/gIQAgmTZYN_blog.html

[3] http://www.symantec.com/connect/blogs/dragonfly-western-energy-companies-under-sabotage-threat

[4] http://www.networkworld.com/article/2188264/malware-cybercrime/dhs--america-s-water-and-power-utilities-under-daily-cyber-attack.html

[5] http://www.computerweekly.com/news/2240207488/US-researchers-find-25-security-vulnerabilities-in-SCADA-systems

[6] http://www.securityweek.com/vulnerabilities-found-schneider-electric-scada-product-line

[7] http://www.computerworld.com/article/2475789/cybercrime-hacking/hackers-exploit-scada-holes-to-take-full-control-of-critical-infrastructure.html

[8] http://www.theregister.co.uk/2014/09/23/app_devs_suck_at_security_says_trainer/

[9] www.coverity.com/library/pdf/the-software-security-risk-report.pdf

[10] http://www.theregister.co.uk/2006/04/13/data_fuzzing/

[11] http://www.mccabe.com/pdf/McCabeIQ-FuzzTesting.pdf

[12] http://www.zdnet.com/blog/security/microsoft-security-guru-get-fuzzing/258

[13] http://www.computerworld.com/article/2516563/security0/microsoft-runs-fuzzing-botnet--finds-1-800-office-bugs.html

[14] http://www.informationweek.com/hacking-contest-reveals-solaris-vulnerability/d/d-id/1010480?

[15] http://www.technewsworld.com/story/75768.html

[16] http://www.zdnet.com/blog/security/stuxnet-attackers-used-4-windows-zero-day-exploit

[17] http://royce.house.gov/news/documentsingle.aspx?DocumentID=397589

Disclaimer

The above post is solely based on my personal research and in no way represent the views and opinions of Codenomicon.