Category Archives: Information Security

Reason that your Application Security Program will Fail – Shiny Box Syndrome

Not long ago, I developed a solution for my employer to assess our customers’ application security maturity and evaluate the effectiveness of their current application security initiatives against their business goals.

While this service helps our customers to understand if their investment in AppSec is yielding the return they desire, it also helps us in understanding “What actually works and what doesn’t when it comes to implementing Application Security Programs at an Enterprise Scale”. This in turn enables us to provide the most effective advise to our customers. For me, the knowledge and experience gained from these assessments feed my passion for “Enterprise Application Security” (I hope my blog posts on this topic reflect it).

So, to share some of the knowledge gained from these assessments with you, I am writing this blog post where I share the Top reason which in “my” opinion is the cause of failure or in-effectiveness of an Application Security Program.


Shiny Box Syndrome
The very first issue faced by the organizations today is “Shiny Box Syndrome”. Information Security is traditionally a product driven field where Information Security teams purchase Firewalls, IPS and IDS devices and implement these to defend the networks or systems from attackers.

The purchase/acquisition of such products raises curiosity in practitioner’s mind and he/she is very enthusiastic about switching it on, watching the blinking lights and then observing it do it’s own thing. This whole process provides him/her a sense of accomplishment but then the curiosity dies and he/she moves on to the next thing. I term this phenomenon of “Acquiring a product, using it to satisfy the curiosity and then moving to the new technology/activity as “Shiny Box Syndrome””. This is perfectly acceptable in this context as once configured Shiny Boxes (Firewalls, IPS, IDS etc.) continue to do their thing even when no one is looking at them (with little periodical health checks and updates etc).

From the assessments we have performed so far, we found that the Shiny Box Syndrome is very much prevalent in Application Security Field as well. The Information Security team will purchase a ‘Static Analysis’ or ‘Dynamic Analysis’ product; perform few ad-hoc scans on random applications to try it and then:
1. Stop using it
2. Implement as a suggested ‘security activity’ within SDLC; conduct the security activity for sometime and then start skipping it (due to not having enough resources) and then ultimately stop using it
3. Tries to offload the ‘COMPLETE’ responsibility to development teams without any guidance and then forget about it.

Dissimilar to Network/System security, Application Security is a different beast. It’s NOT a product driven but a Product Supported stream of information security and requires effective processes around products needing consistent execution by skilled professionals to achieve the desired results.

Not only for security products, this equally applies to manual security assessment practices too such as Threat Modelling. The security team realizes that this is an activity of importance and should be performed within SDLC. A vendor is hired to provide training; few threat models are created and then as the teams get busy in other BAU activities, Threat Modelling initiative never sees the light of day again.

In fact, we also find some SMEs trying to hide the reality of the situation by posing that everything is alright and being done adequately, when it is not. This not only makes the organization loose millions invested in AppSec but also gives the management a false satisfaction that everything that deemed necessary is being done.

So, how do we avoid this?

Achieve Maximum ROI from your Application Security Investment through Effective Governance

To prevent Application Security SMEs from falling into the ‘Shiny Box Syndrome’ trap, the following steps need to be taken:
1. Prior to investing in a technology or security practice, identify the outcomes that you want to achieve from it.
2. In addition to investment in tools, invest in adequate/efficient processes which are customized to your organization’s culture
3. Invest in education of SMEs as well as End Users
4. MOST IMPORTANTLY, create KPIs and Metrics around execution as well as progress and Management MUST ask for an update on monthly basis. More often than not, not having the KPIs is the reason for a security activity not being performed.

I plan to talk about few more reasons that cause Application Security Program failure in my future posts. So, stay tuned!

Secure Thy Databases…

We have come a long way since a bunch of non-interactive pages written in plain HTML were considered to be a cool website. Today’s web sites more often than not are highly interactive, developed using sophisticated client and server side scripting code and with a relational database at the back storing and serving the data needed for website to work… blah blah blah… Well if you are reading this blog, I am sure you know all this theory. So, why I am writing this blog post? Two reasons:

  1. It’s been a long while since I posted last
  2. I found something which I wrote 4 years ago and I believe it’s worth sharing

Today, while going through my documents I came across a whitepaper which I wrote in Nov. 2007 titled “Dealing with Threats to Databases”. Yes, the title is same as that of my presentation at OWASP Australia in 2008. The slides for that talk can be found here.

So, If the paper was written in 2007 and presented in 2008, why am I am posting about it today i.e. in 2011.

Answer: The content of the paper is still valid and points raised are still applicable. If you don’t believe me, the proof can be found in the following links:

If you happen to check out these links, you will know that the vulnerability exploited in both the attacks is SQL injection. SQL Injection is not a new issue and has been around since last 8 to 10 years if not more. The application security evangelists have been preaching the countermeasures for the same since a long time as well. So why is the issue still there? I really don’t know the answer to this. May be the language used by the evangelists wasn’t clear enough or way of preaching/teaching/training wasn’t good enough.

So, here I am to explain the countermeasures to protect the databases once and for all. The next few posts (I promise to post the whole section within a week) will be focused on “Securing the databases”.

Just before ending this post I would like to give a “Mantra” to all the developers to avoid SQL injection. Repeat after me:

Writing dynamic queries is a sin. Parameterized queries will protect us from the wrath of SQLi.”

Writing dynamic queries is a sin. Parameterized queries will protect us from the wrath of SQLi.”

Writing dynamic queries is a sin. Parameterised queries will protect us from the wrath of SQLi.”

“Writing dynamic queries is a sin. Parameterised queries will protect us from the wrath of SQLi.

Make sure you remember this Mantra before coming to read the next post. See you all real soon and till then “ parameterized queries will protect us……