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.

71765A25D6

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!

Infrastructure isn’t so much about servers and apps as it is people and process. “It’s the combination: It’s about developers, business leaders, and operations and security teams working in tandem to automate, improve and accelerate the delivery of software for managing the critical functions of a business – John Jeremiah

Feature Selling vs. Use Cases Selling – It’s amazing

Those of you who know me, are already aware that I am not a sales person or sales specialist of any kind. However, i do believe that everybody is selling something at every moment; to others or to themselves e.g.
If you receive a sales phone call, tele-sales person is selling you “YES” and you on the other hand are most probably trying to sell “NO” to him. Better sales person usually wins.
When you are to buy something, a similar clash happens within your mind i.e. between your logical mind and emotional mind. My emotional mind has been telling me to purchase “Microsoft Surface Pro 3” for a long time now where as my logical mind had an upper hand so far which kept on suggesting that I already have so many devices of that kind (iPAD, Macbook Air and several laptops of various shapes and sizes…) and it will not add any value. But, finally my logical mind lost the battle today and I ended up buying the machine which my emotional mind has been yearning for weeks now.
After the purchase, I asked myself why did i buy it (No doubts, its an amazing machine and I love it)? After thinking for a while, I came to a conclusion that my emotional mind could not win over my logical mind by just looking at features of MS Surface; it’s awesome screen resolution, it is small size or amazing speed didn’t matter at all. The only thing that made my logical mind to loose was the “Use Case” of MS Surface in my personal life i.e. how I can use it to be more productive at home, work or in other areas. The exact use case that my my emotional mind suggested to my logical mind is irrelevant to this post and I will probably talk about that somewhere else. But, the point I am trying to make is:
“If I would have come up with this use case few weeks ago, i would have bought the device there and then”.
Upon realizing this theory, I looked at few of the advertisements from big brands and found that most advertisement campaigns are already using the “Use Case Sales Process” to capture the attention of the prospects. The advertisement of MS Onenote  on youtube is a perfect example of this. No more talking about what cool features it has, the only thing that is shown/discussed is “How it will improve your life?”.

If you want to know why this works, then here it is…
When we talk about features of a product or services, it is up to the prospect to come up with a use case for himself/herself and sometimes prospects are not even bothered to go through the process of coming up with a powerful use case for their logical brain to agree to the purchase. Hence, by talking about “Use Cases” instead of features we directly touch the logical side of the brain by shortening the thinking process and relating the product directly to improving the life of the prospects. This dramatically increases the chances of sale to go through in much shorter time.
So sales guys, here is your new sales process which will help you close more sales…
1. Ask Questions to Know about Your Customer
2. Focus on the Use Cases that Relate Directly to Customer (Features are only important when customer asks about it)
3. Close the deal and take money..
and Entrepreneurs, think about use cases while building the products and not just features.
In the mean time, i will keep playing with my cute, little and yet powerful MS Surface. It’s amazing 🙂
Good Luck!

If you are implementing an Application Security Program, processes need to be thought of prior to hiring plans. If you don’t have the adequate processes, you won’t be sure if you have enough or right people/skillset in team. – Sandeep Nain

AdobeStock_84186737_WM

Keynote Speech – The past is prologue; Trends in Information Security (Cyber Risk report 2015)

In this talk, I will be summarizing our findings related to trends in Information Security Landscape.

As suggested in the latest edition of HP Cyber Risk Report, well known attacks are still commonplace, with vulnerabilities that allowed access to unnecessary files and directories being dominant issues. The report showed that in addition to code based vulnerabilities that liabilities related to application deployment must also be considered to implement effective application security programs.

Even with the dearth of high profile and persistent application vulnerabilities, there is some good news. Results reveal that organizations who repeat security testing significantly lessen their security risk. It’s key in catching vulnerabilities that arise from new configurations, patches, and other application elements that don’t stay static.

Date: March 26, 2015
Time: 9:00 - 4:30 pm
Event: HP Protect Asia Pacific & Japan 2015, Taiwan
Topic: The past is prologue; Trends in Information Security
Sponsor: Hewlett Packard
Venue: Taipei New Horizons
Location: No. 88 Tobacco Road
Xinyi District, Taipei City
Taiwan
Public: Public

Speaking at  – HP Protect Asia Pacific & Japan 2015, Hongkong

The cost of cybercrime for an organization has escalated to $12.7 million a year compared to $3.8 million in 2010. And recovering from a data breach has increased from 14 days in 2010 to 48 days in 2014. While the security industry remains over-invested in products and technology, and under-investment in people and processes, hackers are spending more money and sharing information. Cybercriminals are hard at work in changing and improving their skills to win.

Find out how to safeguard your business by changing the way you invest in and think about security – from the perspective of the criminals targeting you.

Date: March 24, 2015
Time: 09:00-05:00 a.m.
Event: HP Protect Asia Pacific & Japan 2015
Topic: Cyber Defense Centre – Agility for Attack Scenarios
Sponsor: Hewlett Packard
Venue: Langham Place Hotel
Location: 555 Shanghai Street
Mongkok, Kowloon
Hong Kong‎
Public: Public
Registration: Click here to register.

Speaking at ISACA Singapore – Achieving PCI Compliance through Strategic Application Security Program

Not long ago the Payment Card Industry released version 3 of PCI DSS. This new version compared to its predecessor introduces a number of changes, PCI states that these changes are intended to address the maturity of the industry since 2006.  Lack of education and awareness coupled with poor implementation and maintenance are leading causes of breaches today; this update is intended to target these challenges by providing guidance and clarification on the intent of requirements and how to meet them. In this talk we will focus on Requirement 6 – ‘Develop and Maintain Secure Systems and Applications’ of version 3.

In HP’s Fortify Solution Consulting Group, we refer to our SSA (Software Security Assurance) framework to design application security programmes or secure development lifecycle for our customers and hence I often get asked if programmes built upon the SSA framework can help in fulfilling the PCI DSS Requirement 6.

If you have the similar questions, this is the session to attend. In this session, we will cover:

  • How to build a “compliant” secure development lifecycle for development teams using modern software development methodologies
  • Challenges of enforcing secure development lifecycle at an enterprise scale
  • Reasons why most application security programmes fail and how we can collaborate with development teams for easier enterprise adoption while meeting regulatory requirements
Date: January 23, 2015
Time: 06:00 p.m. - 09:00 pm
Event: ISACA Singapore
Topic: Achieving PCI Compliance through Strategic Application Security Program
Sponsor: ISACA Singapore
Venue: National Library Board Building
Location: Possibility Room, Level 5, NLB Building
100 Victoria Street
Singapore
Public: Public

Speaking at OWASP Malaysia – Introducing Application Security In Your Organization? Think Like a Developer

To protect your enterprise from application layer attacks, your application security program needs to be goal-oriented and should be supported by a central team of professionals enabled with the best of the breed technologies; following effective processes. If you are wondering, how you can build such an application security program that effectively leverages secure development methodologies while being scalable and effective for a complex organization, this is the session to attend. In this session Speaker will cover:

1. How to build secure development lifecycle for development teams using modern software development methodologies
2. Challenges of enforcing secure development lifecycle at an enterprise scale
3. Reasons why most application security programmes fail and how we can collaborate with development teams for easier enterprise adoption

Date: January 19, 2015
Time: 9:00 A.M. - 12:30 P.M.
Event: OWASP Malaysia
Topic: Introducing Application Security In Your Organization? Think Like a Developer
Sponsor: OWASP Malaysia
Location: Dewan Seminar, Menara Razak, UTM Jalan Semarak
Kuala Lumpur
Malaysia
Public: Public
Registration: Click here to register.

Speaking at OWASP Singapore – Introducing Application Security In Your Organization? Think Like a Developer

To protect your enterprise from application layer attacks, your application security program needs to be goal-oriented and should be supported by a central team of professionals enabled with the best of the breed technologies; following effective processes. If you are wondering, how you can build such an application security program that effectively leverages secure development methodologies while being scalable and effective for a complex organization, this is the session to attend. In this session Speaker will cover:

1. How to build secure development lifecycle for development teams using modern software development methodologies
2. Challenges of enforcing secure development lifecycle at an enterprise scale
3. Reasons why most application security programmes fail and how we can collaborate with development teams for easier enterprise adoption

Date: January 22, 2015
Time: 6:00 PM - 8:00 PM
Event: OWASP Singapore
Topic: Introducing Application Security In Your Organization? Think Like a Developer
Sponsor: OWASP Singapore
Venue: National University of Singapore
Location: SR10 (Seminar room 10), COM1 Building #02-10, 13 Computing Drive
National University of Singapore
Singapore
Public: Public

Building Application Security Program – 4

This is the final post in the series of four posts. In the first post, we covered the overview of our 3 phase approach to build an application security program, followed by a second post describing the first phase i.e. Assessment and 3rd post providing details on our second phase i.e. Design.

Today, we will discuss the final step i.e. implementing the application security program. This is the phase where we will make a decision on the strategy to implement and actually implement the program.

It is a known fact that the introduction of an application security programme in an organisation is not just a technical challenge,  it also brings a big cultural change with it. It impacts the way people do their day-to-day tasks. Hence, it is important that we introduce the program in phases for easier adoption while discarding the big bang approach.

The figure below provides an example of how the twelve security practices could be divided in phases.

1.png

Figure 1 – Introducing Security Practices in Phases for Easier Adoption

In the first phase, we are only introducing foundational practices i.e. practices required to give direction to an application security program such as ‘Strategy and Metrics’ and ‘Policy and Compliance’. In addition, we introduce the practices, which we deem can be easily adopted by the teams based on the ‘Assessment’ results. E.g. if a development team is using static analysis for measuring code quality, it will more than likely be happy to adopt static analysis for identifying security vulnerabilities as well.

Some of the practices can be further broken down into multiple activities. In which case a practice itself may be introduced in phases e.g. ‘Security Testing’ (as demonstrated in above example) or may only be implemented partially, depending upon business requirements.

Finally, Education is a practice, which is evolutionary and continuous.  Therefore, attributing education to any one phase cannot be justified.  Education doesn’t only refer to providing secure coding training to developers, but all the teams involved in the application security program are to be trained in performing the security activities they are accountable and/or responsible for. New courses are added and existing courses evolve throughout the life of the application security programme.

As demonstrated below, we can foresee the interim maturity state after the introduction of phase 1 and subsequent phases. This may also allow us to visualise if we are heading in the right direction in order to meet business objectives.

2.png

Figure 2 – Program Roadmap to Visualise Interim Maturity State of the Organisation

While dividing the security practices into phases makes it easier for application security processes to be introduced, we should not forget that it is all theoretical at this stage. And, a less effective process introduced to a large audience may become a reason for the organisation to lose trust in the program. Hence, the recommended approach to deploy the program is to start with introducing each phase as a PILOT to a small group, preferably those who participated in the assessment. During the PILOT, we monitor and analyse the impact of introduction of the programme. Based on the observations and feedback, we may need to adjust the processes designed in Phase 2.

As a second step (i.e. prior to introducing the programme to the wider community), we should create a program support team (i.e. a group of individuals from security and development teams) with keen interest and knowledge of application security. Once trained, this team will support the wider audience in effectively using the processes and/or technologies introduced through the programme.

Now, we introduce the programme to the rest of the organisation while continuously monitoring changes (due to the rollout) and periodically assessing what worked and what didn’t. We use this information to expand the programme, refining controls and, lastly, mandating the controls one-by-one.

 

This post was originally published by me at http://h30499.www3.hp.com/t5/Fortify-Application-Security/Building-an-Application-Security-Program-Part-4/ba-p/6631972