Was Ronald Reagan thinking about Phishing when he uttered one of the most famous sayings in history … read more
(ISC)2 announced the release of a brand new certification, entitled the Certified Secure Software Lifecycle Professional (CSSLP), to address educating and certifying people on various aspects of software security.
Covering topics from Secure Software Concepts to Secure Deployment and Operations, weaving through Requirements, Design, Development, Testing and Acceptance, this certification is a welcome addition to the already existing gold standard certifications that (ISC)2 administers such as the CISSP, SSCP, CAP, CISSP-MP/AP/EP.
More information about CSSLP can be found at https://www.isc2.org/csslp
A whitepaper on the Need for Secure Software can be found at https://www.isc2.org/download/CSSLP-white-paper.pdf
My keynote address on “Application Security Trends and Challenges” and the training session on “Advanced Threat Modeling” went well and a few friends have posted some comments about their experience.
Check it out.
http://armorize-cht.blogspot.com/2008/09/owasp-appsec_22.html
http://projectbee.org/blog/archive/owasp-appsec-conf-delhi-day-2-and-more/
http://projectbee.org/blog/archive/owasp-appsec-conf-delhi-day-1/
Representing (ISC)2, the global leader in security education and training as their Software Assurance Advisor, I will be delivering the keynote address on Application Security Trends and Challenges in OWASP India 2008.
If you plan to attend or you will be there, come by and say hello.
Dates – August 20th, 2008 @ 9:00 -10:00 a.m.
Venue – India Habitat Center, New Delhi
More Information, click here
Would you buy your dream car without seatbelts? Didn’t think so … Then why should you settle for software without seatbelts … read more
By design, Web applications are set up to process and present information, generally without the installation of any custom software on the user’s system. All the user needs to view information is a browser such as Microsoft Internet Explorer or Mozilla Firefox. With the current generation of Web application technologies (Web 2.0), Web pages no longer are plain vanilla and static but instead are rich user interfaces that are dynamic. Information is no longer merely presented but can now be interacted with per the user’s personal interests.
Herein lies the problem. If presenting the information is not properly protected, Web applications can suffer from TMI Syndrome (TMIS). TMI, an abbreviation for Too Much Information, according to Wikipedia is a slang expression indicating that someone has divulged too much personal information and made the listener uncomfortable. When Web applications suffer from TMI Syndrome, they divulge more information than is necessary, unsolicited or otherwise. Read entire article on TMI Syndrome in Web Applications – Here
A related Yahoo Video on Hackers targeting social networks.
What do you think Shakespeare had to say about Software Security? What does an naked motorist have to do with Confidentiality? What does the Jungle Book character Baloo have to say about Security Essentials (The Bare Necessities of security)? What does the African Wildlife have to do with Security Concepts? What does pH have to do with Security? and more …
The Road Less Travelled by renowned poet, Robert Frost ends by with the statement “And that has made all the difference”. Come to find out the answers to the questions above and see what it takes to look at Security from a different perspective, that would make ALL the difference. The session will cover not only the higher level abstractions of security concepts, but will dive deep wherever applicable into concepts and code, making it a MUST attend for Development, QA, PM and Management Staff on both the IT and Business side.
At the Austin Open Web Application Security Project (OWASP) session on April 29th, 2008, I presented the following presentation that you can download by clicking on the link below.
![]() |
![]() |
| Security Management(Managing Elephants)? | Sleep Swimming (Vigilant Software) |
In the current day and age, the chief drivers for software development projects are meeting business requirements and deadlines. Security is generally an afterthought for software development projects. Incorporating security from inception is more cost effective.This session will address the various security controls and activities associated with each phase of the software development lifecycle (SDLC). The controls and activities include but are not limited to; modeling use/abuse cases, threat modeling, security code review, security testing, etc.
I presented at the Texas Regional Infrastructure Security Conference (TRISC) on SD3LC – Secure By Design, Development and Deployment. You can download the presentation by clicking on the link below.

Integral – As part of the SDLC
SD3LC – Secure by Design, Development and Deployment
TRISC was held in San Antonio, Texas from April 21-23, 2008. The key note session by Mary Ann Davidson (Oracle CSO) and Dan Korem’s workshop session on the Art of Profiling (from Rage of the Random Actor) was excellent. Getting to meet Woody (Elwood G. Norris), master inventor and technologist with 47 U.S. Patents and 100 others pending was an honor. Another highlight of the event was meeting DefCon’s ‘Deviant’ Ollam who had a training on Lockpicking (Physical Security) through The Open Organisation Of Lockpickers (TOOOL) and learning how to pick a padlock using an aluminium can.
Robert Hansen’s (RSnake) talk on “Why I dont use Web App Scanners, all the time” was a great talk and Doug Landoll’s case study on ”Why Technology has Failed to Solve Security Problems” was rife with real world examples and extremely relatable. There were other great sessions by DenimGroup and Whitehat Security and all of the sessions, I could attend were informative and useful. In addition to the conference, it was Fiesta week honoring the memory of the heroes on the Alamo and the Battle of San Jacinto, and so the city was extremely festive and my family and I had a fantastic time in the city, especially the River Walk.
I find myself often having to explain in more detail (than I felt was necessary) when using the following terms – application security, secure software, writing secure code, hack-resilient applications or any combination of these.To some it was debate about it being more than just buying and deploying a bunch of tools, be it scanners (static or dynamic, vulnerability or code), firewalls (network or web app) or anything else that had a hint of security – aka “the technology” To others it was all about policies, standards and procedures, patterns, practices and governance frameworks with little to no relevance on the technical implementation of security – aka “the governance”. Seldom, it would be about the first line of defense – “the people”. Every now and then, it would be about defined processes (policy checking, security requirements generation involving abuse case/threat modeling, security code review, security testing, vulnerability assessments, penetration testing, exception management, and sign-offs) through the life cycle of software development from envisioning to stabilization – aka “the processes”.
So going forward, I plan on using the term – SD3LC, that stands for Secure By Design, Default and Deployment Life Cycle, a term coined from SDLC (Systems Development Life Cycle) and SD3 (Secure By Design, Default and Deployment)
Let me explain – SD3LC
Secure by
Design (complying to governance),
Default (relevant technology) and
Deployment (security aware people)
Life Cycle (defined processes)
In other words, Secure Software = SD3LC
Recently, John Steer who works with a good security friend of mine, Mark Curphey (a.k.a. SecurityBuddha, Visionary, OWASP Founder, ex McAfee VP of application security consulting and now Microsoft ACE Team Leader) wrote a interesting and good article entitle Security Policies in the Application Development Process.
John Steer writes – The role of a security policy is to define what needs to be protected and how it will be protected. In the application development lifecycle, the security policy instructs designers and developers on what the security features need to be and how they must be implemented.
I couldn’t agree more with John, but with just a little to add. Most organizations have a policy but don’t go as granular to defining an Application Security “Policy”. When they do, it is usually a Application Security “Standard” and if you are lucky, they would have, more granular documents that make up the Application Security “Procedures”. In fact, Policy documents are generally very generic with little to any definitive instructions. This is usually the case to prevent rework of the policy upon change in the business or in information systems and technology. Definitive instructions find their place in Standards or Procedures.
An example of an Application Security Policy, Standard and Procedure (when it exists) would be
Policy – Personally Identifiable Information (PII) must be protected
Standard (Application Security) – When transmitting or storing PII, it needs to be encrypted or hashed
Procedure – When storing PII, use NIST approved AES (Rijndael) encryption with at least 256 bit key strength. For more information see link
The fact remains that whether your organization just has a Policy (or) Policy + Standard (or) Policy + Standards + Procedures, they ALL need to address security in application development. The problems lies, when that is not the case.
John’s entire article can be read here and I would recommend that you do.