Writing Secure code is not a secure SDLC; There are so many other avenues to address when developing an application from regulatory compliance to development to maintenance and deployment of the solution.

Many people mistake “Secure development” with “writing  secure code” they are not the same as secure code is only one part of the development lifecycle.
SAMM covers off many of the aspects that need to be made to ensure the system being developed is of a high quality and adheres to relevant external requirements. For individual new to SAMM it is an “eye opener” to consider the aspects of the SDLC that need to be considered rather than just writing secure code.

SAMM is simple, is can give you some tangible metrics on “how good is our SDLC” process which is a challenge in modern software development and security at a whole….useful metrics which one can act one are difficult to tabulate and put into action in order to address weakness or enhance a process.

SAMM is also a good tool from a strategic perspective as one can develop a roadmap depending on the nature of ones business and external concerns.

See more here:

http://www.opensamm.org/2010/08/samm-and-the-financial-services-industry/

My focus was on snakeoil, code security, Pentest Vs Code review and automated detection of business logic flaws (a pipe deram).

You can hear it here:

Interview with Eoin Keary

Re: OWASP Ireland September 17th 2010

OWASP are holding its annual Irish event in September.

We have the pleasure to announce a number of key figures from industry which should provide some unique insight into the latest trends, threats and methodologies in the world of application security.

http://www.owasp.org/index.php/OWASP_IRELAND_2010

Keynotes:

John Viega: “Application Security in the Real World” – Considerations for AppSec in non-security companies.

John is Executive Vice President of Products and Engineering at Perimeter E-Security. John has authored numerous books on security, including the recent “Myths of Security”, and the seminal “Building Secure Software”, which was the first book on application security.
http://www.owasp.org/index.php/John_Viega

Professor Fred Piper “The changing face of cryptography”

Fred Piper was appointed Professor of Mathematics at the University of London in 1975 and has worked in information security since 1979. In 1985, he formed a company, Codes & Ciphers Ltd, which offers consultancy advice in all aspects of information security. He has acted as a consultant to over 80 companies including a number of financial institutions and major industrial companies in the UK, Europe, Asia, Australia, South Africa and the USA. The consultancy work has been varied and has included algorithm design and analysis, work on EFTPOS and ATM networks, data systems, security audits, risk analysis and the formulation of security policies. He has lectured worldwide on information security, both academically and commercially, has published more than 100 papers and is joint author of Cipher Systems (1982), one of the first books to be published on the subject of protection of communications, Secure Speech Communications (1985), Digital Signatures – Security & Controls (1999) and Cryptography: A Very Short Introduction (2002).
http://www.owasp.org/index.php/User:Professor_Fred_Piper

Damian Gordon Phd: “Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking”

Damian Gordon is a lecturer with the School of Computing at the Dublin Institute of Technology and is Programme Co-ordinator for the School’s Masters in Computing (Assistive Technology). He was primary researcher on two EU funded projects whose particular focus was looking at issues associated with technoacceptance – the ILT and the E4 projects – and was Educational Advisor for the Ireland-China EMERSION project. His research interests include Differentiated Instruction, Computer Security, Technostress, ICT and Special Needs, Virtual Learning Environments, Image reconstruction from specular reflections, and Lateral Thinking Techniques.
http://www.owasp.org/index.php/User:Damian_Gordon

We also have some great international and local speakers covering topics from Smart phone application security to SDLC to Penetration testing techniques:
·         Dan Cornell (”Smart Phones with Dumb Apps”)
·         Ryan Berg (”Path to a Secure Application”)
·         Dr Marian Ventunaec (”Testing the Enterprise E-mail Security – from Software to Cloud-based Services”)
·         Fred Donovan and (“Counter Intelligence as Defense……”)
·         Nick Coblentz (“Microsoft’s Security Development Lifecycle……”) but to name a few

http://www.owasp.org/index.php/OWASP_IRELAND_2010#Agenda_and_Presentations_-_September_17

Training:
http://www.owasp.org/index.php/OWASP_IRELAND_2010#Training

Secure application development training shall also be held on the 16th (day prior to the event):

“Secure Application Development: Writing secure code (and testing it)”

Testing shall be delivered by
Eoin Keary, OWASP board member and “The OWASP Code Review Guide” (http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project) Lead
Rahm Jina, Senior consultant with Ernst & Young.

This intensive one-day course focuses on the most common web application security problems, including aspects of both the OWASP Top Ten (2010) and the MITRE Top 25.
The course reqires interaction and Lab exercises using the OWASP Live CD.
The course will introduce and demonstrate application assessment techniques, illustrating how application vulnerabilities can be exploited so students really understand how to avoid introducing such vulnerabilities in their code, covering of the following areas:

Unvalidated Input
Injection Flaws
Cross-Site Scriping
CSRF
Authentication & Session Management
Access control & Authorisation
Broken Caching
Error Handling
Cryptography
Resource Management
The Secure SDLC

Training shall occur on the 16th September followed by an intensive day of talks on the 17th.

http://www.owasp.org/index.php/OWASP_IRELAND_2010

OWASP Ireland 2010

There are many stats that come out on an annual basis from IBM, CSI, White Hat, OWASP etc which cover off statements such as “75% of sites contain a vulnerability” of “42% of sites tested had a cross site scripting issue”. Ok fine cant argue with that but how many of the vulns are useful to an attacker to perform an actual attack?

Brand damage is a major concern for organisations in relation to cyber security breaches. The actual attack or attempted attack does not do too much damage but if the media get wind of the incident it can be spun out of control.

I believe the “securing the parimeter” idiom is out of date and leads to a false sence of security. In my day to day work I am encountered by more and more organisations suffering loss but the attack vector is attacking the client not the organisations itself. Its more common than successfull SQL injection in my opinion and is a softer target.

PCI is totally inadequalte in relation to this type of attack and the best solution is careful design; such as using one time passwords (expensive), enfrocing business logic such that it is difficult to commit significant unauthorised transactions. Using out of band messaging such as mobile phone txts to inform the user a transaction has taken place. Is there even value depending on your business model to block particular IP blocks  relating to a geographic area given you do not do business in that region?

The time was short and code base big; Out come the static analysis and fault injection tools. (”This should help us get ahead of the curve” – or so I thought!)

The systems were critical  financial systems developed by a well known integrator so one would think, “this is going to be good quality“.

So as an initial step in terms of execution once I have established context is to throw the tools at it.

Fault injection tool: A tool which is a market leader. The tool couldn’t even crawl the site.  For some strange reason which still bemuses me it could not see responses from the application.

Verdict: No use, We even pointed some verified XSS vulnerable links to it but it simply did not see the issues, funny that eh?

So we took the manual assessment approach which yielded some interesting results……

Onto the code review: Yes another commercial tool was used, yes it found lots of “stuff” but none I could say posed significant risk to the business (lots of issues to fix but no high risk issues).

Actually,Surprise surprise, this code was some of the worst garbage I have ever reviewed in the last 6 years!!.  It was so bad with so many layers of linkage the tool initially decided not to even review portions of the code! (But to know this the error log was required to be reviewed – Good to know, i suppose  given that this is a code review!!)

So what next:

Lets look at the the application in the manual sense, code review, line by line, transactional analysis, data flows, error handling etc…..

“Oh look” no authorization on any client request, so what can I do here??

First of all, a code review tool can’t comment on code that does not exist. The best way to fool a code review tool is not to have any code to review.

So, back to authorisation:

Lets transfer funds to an arbitrary account, seen as there does not seem to be any authorization, say €100,000,000.

Oh Look that worked!! and it also reconciled on the bank balances!!!

So now we have established the potential for massive fraud by altering the TO and FROM account Numbers.

The issue here is that the vulnerability is lack of logic reflecting business requirements. Technical issues such as XSS, SQLI, CSRF, SSI etc can be found by tools via signature/response but circumvention of business logic produces no apparent vulnerability signature for which tools can detect. – This is an important point to consider.

So even with an automated 360 review (code review and app pen test) such tools can not discover fundamental flaws in the systems logic which take no skill to exploit. – Still requires mushy human grey matter

Why talk about SQL injection (SQLI) ? It has been the most common attack type in recent times, anyone from large banks and retail organisations to governments have been hit. RBS: $9 million  in 30 minutes, US ARMY

OWASP cheat sheet

Sans SQL Injection worms whitepaper

Such a flaw would not be uncovered by automated scans or automated code review. So ASVS Level 1A or 1B would not be sufficient!

Human intervention, data flow analysis and business logic review from a security standpoint coupled with manual testing may of uncovered such an issue.

read more on here

O2 is an Open Platform for automating application security knowledge and workflows

http://diniscruz.blogspot.com/2009/09/o2-open-platform-for-automating.html

Dinis Cruz shall be detailing the O2 solution and shall be available for discussion.