People management – a primer

Leave a reply

People management is a skill that is simple to learn but takes years to acquire. In this post, I am writing a crux of 10+ books that I have read on the topic. Simply put, people management has four dimensions:

Team Member Management: Assess the individual’s competency and accordingly provide autonomy. Unblock them as needed. Provide actionable feedback. Support them in achieving their professional goals and career growth. 

Team Management: Give the team a direction and guard rails to ensure it works towards achieving business goals. Ensure the team is effective and efficient. 

Peer Management: Have empathy for peers; understand their priorities and effectively communicate your team’s priorities. Work as one team to meet the business objectives

Upward Management: Understand the “needs” of the business and management and proactively work towards meeting those needs. Note that it is understanding the ‘Needs’ and not ‘Wants’.

‘Peer management’ and ‘Upward management’ are typically the least understood dimensions and new managers tend to miss.

Finally, work towards building influence and not hierarchy.

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

2 Replies

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 www.canadianpharmacy365.net 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!

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

Leave a reply
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 ppmhc.org Bactroban 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!

Building Application Security Program – 4

Leave a reply

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 www.snanc.org 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

Building Application Security Program – 3

Leave a reply

This is the 3rd post in the series of four posts. In the previous post, we looked at the first step of building an application security program i.e. Assessment.

In this post, we will discuss the proven approach to design an effective and scalable application security program for an enterprise.

By the time we enter the Design phase, we already have an understanding of organization’s security culture including:

  • Software security objectives
  • Security activities being performed and corresponding effectiveness
  • Strengths and weaknesses of existing software development and security teams as well as processes

In design phase, we further process this information to identify the actual gap between the current level and the desired level of software security maturity. We create a plan to fill the identified gaps while leveraging the organization’s development team’s strength. For which, we take the data collected during assessment and mix it with industry best-practices in order to produce lightweight, easy to adopt processes and actionable guidelines that can be easily introduced in the organization.

The artifacts produced during the design phase and the approach to create these artifacts is explained below:

Security Requirements: Almost every organization needs to comply with requirements enforced by one or more government or industry regulatory bodies to stay in the business. Hence, we start with identifying the software security requirements and processes the organization must perform to satisfy compliance mandates. These requirements are then correlated to other security requirements compiled to achieve business objectives. The resultant list is a single comprehensive set of security requirements that the programme needs to achieve through adequate and effective usage of people, process and/or technology. A set of technical controls with implementation instructions is also created to fulfil the defined security requirements.

Secure Software Development Lifecycle:  Next step in the design phase is to create a secure Software Development Lifecycle which is the core of any application security programme. It is not recommended that a new armodexperiment.com process be created from scratch unless absolutely necessary. Instead, we should take the organization’s existing SDLC process and improvise it by seamlessly weaving the security activities in it while ensuring the process enables the organization to meet the security requirements compiled earlier. The secure SDLC should clearly identify which security activities are to be performed manually and which could be automated.

Roles and Responsibilities: Several application security programmes fail despite having a good, secure SDLC. This is mostly because, although security activities have been defined within the SDLC, no one is made responsible or accountable for the execution of these activities.  Therefore, it is very important to clearly identify the responsibilities and accountabilities for the defined security processes and activities.

In the image below, a sample RACI chart is shown for static code analysis activity. It explicitly defines that the Development Team Lead is accountable for scanning the code, whereas the Information Security Team is responsible for triaging the results of static analysis with the consultation of development teams.

RACI_Chart_Static-Code_Analysis.png

EXPLICIT_INSTRUCTIONS.png

Application Risk Classification Criteria: Not all applications pose the same risk to the organisation hence, it is not viable to perform equivalent security measures on all applications. To overcome this, we create “Application Risk Classification Criteria” in which we can utilise the application attributes such as data being handled by the application, accessibility, business criticality, etc to define the potential risk of the application. This can help development teams identify security requirements the application must comply with and which technical controls are to be implemented to fulfil these requirements.

Software Security Education Matrix: It is a known fact that an application security program requires a thorough, role specific and methodical software security education program to be successful. Hence, we use the assessment results to identify the area of focus and create a training matrix suggesting what role specific trainings are required.

Once all these artefacts have been prepared, we are ready to move into our next phase which is implementing the application security program. This will be discussed in the next and final post of the series. Stay tuned!

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

Building Application Security Program – 2

Leave a reply

This is second in a series of 4 posts. In this series, we are discussing the recipe to build and implement an effective application security program. If you haven’t already, I suggest you to start from first post.

The first step of an organization’s application security journey should be “Assess” i.e. Assessment.  In this step, we want to understand:

  • Organization’s Software Security Goals
  • Software Security activities performed in the organization and the depth of the execution of these activities
  • Strengths of the development and operations teams as well as areas requiring attention based upon business goals and objectives.

All this information is then used to design the program which we will cover in the next post.

Assessment can be divided into two phases:

Software Security Strategy Assessment

This is the most important getzonedup PowderCity task in the Application Security Program Lifecycle as the whole program revolves around the results of this phase.

It starts with Identifying organization’s software security goals and objectives. The best way to gather this information is by interviewing the business leadership in order to:

  • Understand organization’s vision and business goals
  • Evaluate executive’s understanding of their software security needs i.e. is there adequate buy-in from management
  • Identify the impact of lack of software security to business goals.

Once business goals have been identified, the data-related, existing software security initiatives and practices are documented. This is performed by:

  • A series of interviews with relevant Software Security Assurance (SSA) program stakeholders involved in project management, security, requirements, design, development (in-house and outsourced), and deployment processes
  • Reviewing existing organizational software security policies, SDLC artefacts, secure coding standards and guidelines.

Interviewing the stake holders provides insight into organization’s attitude towards software security initiatives whereas reviewing the documents help with an understanding of whether the activities are actually being performed and how well they are being performed.

Assessing the security strategy could be a complex (and ambiguous) task unless guided by a proven framework or maturity model and there are few available for this purpose. Two such popular models are described below:

BSIMM

BSIMM is a descriptive maturity model and describes a set of security practices as conducted by global participants, with real-world data from 67 firms including Microsoft, Adobe, Zynga, Salesforce, Citi, Bank of America, Box, Paypal and many others ( www.bsimm.com/community ). Results of a BSIMM assessment can be used compare the initiatives with peers and industry leaders already participating in the studies. For more details, refer www.bsimm.com

OpenSAMM

OpenSAMM a.k.a. SAMM is prescriptive model to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. For more details, refer www.opensamm.org.

 By mapping the information gathered to these maturity models, a current security state model as well as a future state model can be created for the organization.

Software_Security_Assurance

Technical Assessment

Although interviewing the stakeholders and reviewing the documents is one of the most effective ways to assess the software security maturity of an organization, it fails to provide two important pieces of information:

  • Technical impact of gaps in security strategy – important for building business case to achieve management support for the next stages of the program
  • Secure coding areas requiring most focus during the trainings to be provided to development teams

This part is easy and can be achieved either by performing the security assessment (Code Review and Penetration Test, in tandem is preferred) and evaluating the results OR by reviewing the recent security assessment reports for some of the major business applications.

 From Assessments we have gleaned three important pieces of information.

  • Where we are
  • Where we need to be
  • Strengths we can leverage and weaknesses we need to overcome

 And once we have these three things, our journey becomes easier…

In the next post, we will look at “Designing an Application Security Program”. We will discuss what needs to be covered in the program and related gotchas.

 

This post was originally published at my employer’s site by me.

Building Application Security Program – 1

Leave a reply

In this blog post, i’ll answer the question: What are the expectations of Secure Development Lifecycle at an enterprise level, and how can an application security program be built and implemented to meet these expectations?

It’s been a number of years since we started promoting the Secure Development Lifecycle, which suggests that security activities should be performed at each step of the SDLC. These activities being:

  • Security requirements analysis
  • Threat modeling
  • Security architecture reviews
  • Code reviews
  • Penetration testing, etc.

Proactively performing these activities enables us to produce secure software most efficiently and at lower costs.

But, things are easier said than done. No two software systems in an organization are the same, and performing all these activities and implementing each and every control in the security book may turn out to be overkill in some situations, while causing unnecessary shake-up in the project cost.

Furthermore, when we are talking about introducing SDLC and associated activities at an enterprise level, we are looking at some investment from the management; and whenever there is an investment, there are expectations. These expectations can be summarized as:

  • Reduced risk at low operational cost
  • Compliance with regulatory requirements
  • Measurable return on investment
  • Security culture within the organization

Hence, this enterprise-wide rollout of Secure Development Lifecycle needs to be considered as a program–an application security program with defined objectives and outcomes.

So, where do we start?

What are the various steps we need to follow to build an application security program?

As we all know, there are no two organizations that are exactly the same.

There are no two software development teams that are exactly the same.

And there are no two applications that are exactly the same.

Hence…

There is no silver bullet, no one, boxed product that can be the solution.

The approach that we have seen to work the best is a 3-step approach. The 3 steps being:

pic-ssa.png

Assess

In the assessment phase, we measure the current security maturity state of the organization, which includes assessing:

  • Where we are today from a software security perspective
  • Where we need to be
  • The strengths we can build upon and weaknesses we need to overcome

Design

The intent of this phase is to extract material from first phase, mix with industry best-practices to produce lightweight, easy to adopt processes and actionable guidelines to be used by development and security teams.

This is the phase where we come up with a plan to fill the gaps identified in the previous phase while leveraging the organization and development team’s strength.

Implement

This is the phase where the program is put into practice.

Stay tuned for the next blogs in this series where we explain these three phases in detail.

NOTE: This post was originally published here… by me.

Building Dependable Enterprise Applications

Leave a reply

Howdy all, I know I did not keep my promise to regularly update this blog. But, before you start firing at me let me tell you the reason for it.. No, its not an excuse – I have a valid reason for it. In fact a good reason for not blogging regularly.

My life has changed since my last post. My dear wife gave birth to our first child 10 weeks ago. A beautiful angel daughter.. So, life is a little busy.

However, last night i got a chance to write about application security which ended up as a blog post on my company’s tech blog under the title Building dependable enterprise applications. You can access it at

http://www.purehacking.com/blogs/sandeep-nain/building-dependable-enterprise-applications.

Have a read online-pharmacy.org and feel free to let me know what you think of it. It’s the time to sing lullaby for the little baby. So, I’ll say bye for now and hope that I will return very soon to write something new.

Secure Thy Databases…

20 Replies

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……”

Related articles

Story behind this blog!

1 Reply

Someone once said to me “If you can walk with the crowd, still hold your head high and stand out, then you would have arrived“.

Since that day “to arrive” has been my aim and while walking on the path to achieve this, I found many, left many and then there were few which I kept close to my heart. Not talking about people here (ofcourse it applies to people too) but the software development lessons which I learnt from my peers, teachers and many considerate programmers who share their code with the needy ones through internet. So, here I am to share the good software security practices through this blog with a belief that one day this endeavor of mine will contribute to the secure software development in various organizations around the world hence building the foundation of a vulnerability free cyber world.

In this blog, you will find what programmers should and shouldn’t do to ensure their applications are resilient to attacks in addition to some good practices being followed in various organizations around the world to produce secure software.