Tribute to Software Security Guru Roman Hustad

Roman Hustad, OWASP chapter leader in Sacramento, CA, died suddenly on November 4th at the age of 39, the result a fatal heart rythm caused by an enlargement of his heart, the cause of which is still unknown. He collapsed after arriving in the Las Vegas airport that evening.  Roman suffered virtually no pain and was surrounded by others. 

Roman is survived by his wife of 6+ years, Tanya (Burgdorf) Hustad, and his sons Lucas (4 yrs old) and Wyatt (2 yrs old), his sister Holly (Fail) Hoeksema, and brother, Andrew James. The whole family is being supported and cared for by loving family and friends in Davis, CA at the moment.

This is also a big loss for OWASP and the appsec security community. I've known Roman as a former colleague at Foundstone and I worked with him at a four month software security gig for a financial client in Orange County, CA in 2006.

Roman was a person of high professional standards, strong integrity generosity and ethical values. Professionally, he was a top notch principal software security consultant and one of the best if not the best JAVA security trainer that I ever known. After I left Foundstone in 2007, I regret that I did not kept in touch with him. I will always remember him as one of the best software security consultants I had the pleasure to work with.

As a tribute to Roman published work I have provided some references herein.

Hacme Books vs 2.0 Strategic Secure Software Training Application http://www.foundstone.com/us/resources/whitepapers/hacmebooks_userguide2.pdf

Papers on SoftwareMag.com, such as:

 "Implementing a Software Security Training Program" http://www.softwaremag.com/L.cfm?doc=1174-10/2008

"Holistic Approach for Secure Software" http://www.softwaremag.com/L.cfm?doc=1155-8/2008

Roman also published a paper for ISSA Journal, on "How virtualization affects PCI-DSS, A review of Top 5 Issues": https://dev.issa.org/Library/Journals/2010/January/Hau-How%20Virtualization%20Affects%20PCI%20DSS.pdf

Recent Acquisitions In The Security Industry And What It Means For Software Security Professionals



The recent news of the acquisitions of McAfee by Intel and of Fortify by HP can be interpreted as a future trend for the security industry: build security into hardware and engineering processes instead of bolting security on products. Intel's acquisition of McAfee for example, can be interpreted as move by Intel to integrate application security with hardware (e.g. microchips) that Intel currently develops. Similarly, the acquisition of Fortify Software by HP can be interpreted as a move by HP to integrate software security within HP suite of tools for software testing. Moreover, the news of McAfee acquisition by Intel, can also be interpreted as that the age of companies as pure providers of Antivirus tools has come to an end. This was also predicted by John Kula in his book, Hacking Wall St attacks and countermeasures: ”By the end of 2010, conventional pattern matching anti-virus systems will be completely dead. Their effectiveness will have fallen below 50%."

To understand how signature Anti-Virus (AV) detection and eradication tools have come to age, we need to look at the evolution of security threats in the last two decades and how this affected the effectiveness of AV tools in mitigating the current threats such as cybercrime threats. This is mostly due to the fact that the security threats that consumers and businesses have to protect from today are very different from the ones that they had to protect from ten years ago. In the 90’s the main targets for viruses were users' PC, typical attack vectors included opening unknown email attachments to infect their PCs and spread to the company servers. In 2001 we witnessed the appearance of the first malicious rootkit for the Windows NT: such rootkit had the capability to sneak under the radar of the anti-virus software and evade detection. In 2003 denial of service attacks took advantage of the spreading of worms for infrastructure wide exploitation of buffer overflows such as the SQL slammer worm that caused denial of service to several ATMs at banks such as Bank of America and Washington Mutual. As new signatures were developed to detect and eradicate viruses and worms, the effectiveness of Anti-Virus tools stood on the capacity to identify viruses and worms by the unique signature of the attacks as well as in the capability to eradicate viruses and worms after the infection by patching the infected system. But in 2005, we witnessed email phishing attacks to spread Trojans programs embedded in apparent harmless files eluding anti-virus software and firewalls with the purpose of data exfiltration such as to steal passwords and sensitive data. In 2007, we had the evidence of botnet controlled trojans used as crimeware tool to rob online bank customers, spreading either through targeted phishing attacks or through drive by download infections. More recently, in 2009, Trusteer a security company providing anti-malware solutions published an advisory entitled “Measuring the in-the-wild effectiveness of Antivirus against Zeus” according to which the most popular banker malware Zeus, is successfully bypassing up-to-date antivirus software : "The effectiveness of an up to date anti virus against Zeus is thus not 100%, not 90%, not even 50% - it’s just 23% “.

It is therefore clear in my opinion, that the defenses for malware infection, being this with either viruses, trojans or worms have to be expanded to include other layers of the technology stack that are now the target for rootkits and malware attacks. These expanded layers might include for example, besides the O.S and the application also hardware, kernel and firmware that are currently below the radar of AV detection tools.

Expanding security protection to the hardware layer is beneficial not only as detection control such as for malware intrusion detection but also as security risk preventive controls such as data protection. In the case of cybercrime, malware rootkits such as ZeuS for example that seek to compromise the communication channel between the PC and the banking sites, the malware attacks the client to either hook into the kernel to do Man In The Middle (MiTM) attacks or into the browser APIs to do Man in The Browser (MiTB) attacks. In both cases of these attacks, there is a lot of security to gain at the application layer by protecting the data at the hardware layer. One way to defeat MiTM attacks for example is to secure the communication channel through 2-way mutual authentication and PKI using client identities that are protected by the so called "ID vaults" embedded in hardware chips and secured at firmware layer. Examples of this "ID vaults"are the Broadcom USH Unified Security Hub, that is included in several PCs today and is leveraged by data protection tools such as Verdasys's Digital Guardian data protection solution. You might also consider the benefit of developing application with hardware defenses such as by enforcing firmware controls by digital signing your application at the firmware layer. For the ones of you that attended the talk from Barnaby Jack about jackpotting ATMs at BlackHat this year, signing the application at the firmware layer was one of the mitigations being recommended against rootkit infections.

The other big opportunity for security companies is the integration of security of software with hardware such as in the case of applications for mobile phones. As software is built for the specific mobile O.S. (e.g. Android or iPhone O.S.) can also be build out of the box by leveraging security controls deep in the technology stack that include kernel API, firmware and hardware. In the case of being capable to detect attack vectors, having intrusion detection events that can be triggered at the different layers of the technology stack can leverage defenses at the application layer such as blocking the application to run or transferring data to the server. These are just few examples of security synergies accross layers of the technology stack.

In summary, I think Intel acquisition of McAfee could give Intel the opportunity to design hardware chips that tightly integrate security detection and prevention controls with firmware and software and provide additional layers of security to applications.

The other industry M&A news was the acquisition of Fortify’s software security company by HP: this follows a trend of big software companies such as IBM and HP to acquire security tools companies such as Watchfire and Fortify. Previously, HP grew their security assessment suite of tools through the acquisition of SpyDynamics WebInspect to integrate it in HP's software quality assurance suite of tools, QA inspect. Since IBM previously acquired application scanning tool WatchFire’s Appscan and static analysis tool provider Ounce Labs, Fortify’s static analysis tool acquisition by HP fits the scenario of HP competing head to head with IBM in the software security space. For sake of competition, the acquisition of Fortify by HP make a lot of sense, but the HP acquisition of Fortify also fits the trend in the industry of run software security either as a service or as an assessment integrated as part of the Software Development Life Cycle (SDLC) process.

For example, application and source code vulnerability scanning assessments, referred as dynamic and static testing can be performed a Software Security as a Service (SSaaS) for software development stakeholders such as application architects, developers and testers. These services can also include automation security tools that can be rolled out as part of the overall software development and testing suite of tools such as Integrated Development Environments (IDE) and Q/A testing tools. Obviously, security tool integration with IDE and Q/A testing tools is just one part of the software security equation, as besides tools you also need to roll out secure coding training and secure coding standards. The holistic need of software security that includes people process and technology, is often misunderstood by who has to manage software security initiatives for organizations as software security tools or services alone are mis-interpreted as sufficient to produce secure software.

To produce secure software with a level of software security assurance that is both risk mitigation and cost effective, organizations need to roll out, besides static and dynamic analysis tools and services also software security training for developers and software security engineering processes/methodologies such as SAMM, BSIMM, MS-SDL-Agile, Securosis SSDL, OWASP CLASP.

Obviously, the increased adoption of static and dynamic analysis tools by the enterprise follows the application and software security tool adoption trend. If you refer from a survey from errata security –Integrating Security Info the SDLC http://www.erratasec.com/ErrataSurveyResults.pdf, it is shown for example that static analysis is the most popular activity (57%) followed by manual secure code reviews (51%), manual testing (47%). The trend of adoption of application and software security tools usually follows the enterprise awareness of the application security problem as a software security problem.  At the beginning of the rolling out an application security initiative, companies start from the far right of the SDLC by rolling out application scanning tools and ethical hacking web assessments and then move toward the left of the SDLC with source code analysis. Eventually the awareness of the software security problem moves to the design stage by trying to identify security design flaws earlier in the SDLC with the Application Threat Modeling (ATM). Right now, according to the errata security survey, only 37% of organizations have adopted ATM as part of the SDLC. I believe the trend will lead to that direction of adopting ATM because of the efficiencies and the larger security coverage that ATM will provide. Probably this low ATM adoption can be explained by not enough security awareness yet onto the benefits of ATM as well as the maturity levels reached to seek adoption of ATM within the SLDC.

Software security training for developers is also a trend, 86% of the participants of the survey sent one or more members of the software development team to security training. But again according to the Errata security survey, software security is not yet part of the top list of information security management concerns as only about 1/6 of participants (16%) sends his project managers and InfoSec and AppSec directors to software security process management training.

As the static and dynamic security testing adoption grows in the industry there will be also a need of software security services such as software security training and the development of engineering processes and standards. This trend follows the integration of the organization SDLCs as well as InfoSec/AppSec and Risk management processes with formal software assurance methodologies and activities such as vulnerability assessments, secure coding reviews and secure design review/ application threat modeling.

These trends in the M&A of software security industry will also create new career opportunities. In the case of information security managers for example, there will be a need to hire managers with the right experience and skills in managing software security processes for organizations. In the case of software engineers and security consultants, it will create a need of software engineers and consultants abreast of software security formal methods, static and dynamic analysis tools as well as security assessments such as secure code reviews and application architecture risk analysis and design or application threat modeling. In the case of electrical, software or computer system engineers, the knowledge of hardware and software security could also be leveraged to become an expert in hardware-software security integration such as in the case of the design of hardware embedded application security products/solutions.

In conclusion, as software security practitioner, in your current professional role of information security manager, software security architect, software security consultant, software security trainer/instructor you might look at these industry trends to set your career goals and cultivate the necessary skills and experience that could lead you in new career opportunities being created as results of these security industry trends.

White Board Software Security Question #2

What is wrong with this code?


char * foo(int len, char* value)
{
char * buf;
buf = (char*)malloc(len + 5);
if(!buf)
return (NULL);
try {
if(len <= 5) memcpy(buf,value,len); } catch (Exception* ex) { Console::WriteLine(S"Generic Exception Handler: {0}", ex); } return buf; } For finding the answer, think which values passed to "len" might create a problem. For example, look at this code that call the function "foo" #include "stdafx.h" #using
using namespace System;
char* foo(int l, char* value);

int main()
{
char value[]={'H','A','C','K','\0'};
char* buf;
//this will work
buf = foo(5,value);
//this will overflow the buffer
buf = foo(-4,value);
return 0;
}

Basically the problem of this code is that is prone to integer overflow. When len is negative (e.g -4) the amount of memory allocated for buf is one byte (-4+5). The call to memcpy will take the size_t (unsigned int) (4) value and will try to copy a value in "buf" that will be larger than the one that can be allocated by "buf".

In general, integer overflows occur when a program fails to check that an arithmetic operation can result in a quantity either greater than a data type's maximum value or less than its minimum value. This can happen when comparing values that have been casted (for example from int to long that is from 16 bit to 32 bits and compared to max boundaries that can be bypassed since the sign is maintained during casting such as exceeding the actual representation for int that is 32K). In the example herein, the cause of integer overflow is due to the memory allocation function, where user input stumbles with an implicit conversion between signed and unsigned values (like done in memcpy() for example). An attacker can cause the program to under-allocate memory (set len to -4) so that the program may be vulnerable to a buffer overflow.

White Board Security Question #1

Are Store Procedures (SP) SQL injectable?

Answer:

SP protects from SQL injection when SQL statements are executed independently from the input parameters. The same applies to prepared statements. When I say "independently" I am addressing the fact that the input is not embedded in the SQL statement but passed as parameter to a precompiled SP. SQL injection is possible in store procedures when the EXEC statement is embedded in the SP to execute a SQL statement that is passed as input parameter. Such input parameter can be a concatenated string that could be altered with user input. The same applies to prepared statements used badly such as when still concatenate inputs before being executed.

For example, let say you have a SP such as

CREATE PROCEDURE dbo.doQuery(@query nchar(128))
AS
Exec(@query)
RETURN

this SP can execute whenever malicious input is passed to the SP as a parameter.

As a best practice you should avoid to execute SQL statements internally to a store procedure and instead call the execute externally and passing the input query parameters through a parametrized query.

For example, this is a way to call a store procedure with parametrized input parameters:

string str ="sp_doQuery";
cmd= new SqlCommand(str, sqlConn);
cmd.CommandType= CommandType.StoreProcedure;
cmd.Parameters.Add("param 1" p1);
cmd.Connection.Open();
SqlDataReader read= cmd.ExecuteReader();

In this case the parameters cannot alter the syntax of the query statement embedded in the store procedure.

Assuming that you indeed for some reason you still want to execute the sql statement passed as parameters to the SP you might want al least to check the input internally with a regex such as:

CREATE PROCEDURE dbo.query.doQuery(@is nchar(4))
AS
DECLARE @query nchar(64)
IF RTRIM(@id) LIKE ‘[0-9][0-9][0-9][0-9]’
BEGIN
SELECT @query =’select ccnm from cust where id =’’’ +@id +’’’’
EXEC @query
END
RETURN

SP can offer an additional protection from SQL injection because you can set up user permissions to run the SP and prevent execution from untrused code. As a best practice you want the application to run minimum privilege (for example not use sa account to run queries).

From the security stand point this add ianother layer of security even if adds some admin overhead (e.g. set permissions to each SP in declarative way).

I would say that if you stick with use of SP with prepared statements and parametrized queries (no concatenation of input parameters) and if you do input validation of input parameters inside and outside the SP you are in good shape on mitigating SQL injection with SP.

Metaphors in Security

Domain Specific Metaphors can help users to understand security especially when there is no physical example of it such as in the case of public key encryption. A metaphor to explain public key encryption would consist of a public lock and a private key. Open locks for an email address will be widely distributed so everybody shares the same key and can close the lock (secure) the message for everybody else. When a message is secured with a lock (encrypted with a public key) it would then in the closed state and therefore impossible to open without the private key held by the recipient. Every recipient could only unlock the message with the use of their private key. This is all perfectly natural and well understood from the use of padlocks and keys in the physical world. The sender's copy of the message would be associated with his or her own lock as the security mechanism, allowing users to understand the role played by their own keys.

Empirical Formulas in Security

When you need to explain a difficult concept, sometime is easy to visualize it through empirical formulas. Another good way is visualize a concept with metaphor (my next post). In security I found out useful the following formulas:

Security depends on policies, tools and commitment from management:

Security= (Policies^2+Tools)*Commitment

In the formula there is more emphasis (importance) on policies and procedures than tools.

If I change policies by a factor of 2 than security changes by a factor of 4. If I change tools by a factor of 2, security changes by a factor of 2. Basically there is more payoff on changing policies and procedures than tools. Commitment is the most critical since is a multiplier. If there is no Commitment there is no security nullifying all the roll out of policies and the expense on buying tools.

Interesting empirical formulas can also be used to explain risk. Assume the basic formulation:  a Technical risk is the likelihood that threat will exploit a vulnerability to cause an technical impact to the system:

Technical Risk = Threat X Vulnerability X Impact

If you would like to put the emphasis on assets as relate to impact you can also formulate risk as: Risk is the probability of an attack on an asset exposed by vulnerability, Qualitatively can be HIGH, MEDIUM or LOW:

Qualitative  Risk = Vulnerability * Asset * Attack

For example there is a threat but the application is not vulnerable (Vulnerability=0) so there is no risk. Or there are both threat and a vulnerability but there is no asset data (Asset=0, Impact=0) so there is no risk.


Keep in mind that these are empirical formulations for qualitative analysis and not formulation for quantify risk while doing a cost vs. benefit risk analysis such as cost of loss vs. benefit of money invested in security control. The risk of quantitative loss can be formulated as Annualized Loss Expectancy (ALO) = Single Loss Expectancy (SLO) * Annual Rate Of Occurrence (ARO)).

ALO =  SLO * ARO

You can use these risk qualitative formulas to introduce the concept of security risks and of the main factors that can be used for qualitative risk analysis.