Information Security Risk Management Programs Part 3

Thursday, April 21, 2011

kapil assudani


Information Security Risk Management Program: Business Threat Modeling, Baseline Threat Modeling & Reference Architectures 

The first and the second post in this series can be accessed here and here.

In my last (i.e second post), we identified corporate security policy as one of the tools that enforces security in an enterprise. Thus we worked on shoring up our corporate security policies at least to a point which baselines enterprise security and embed applicable industry regulations. 

In this post I would like to propose alternate security service methodologies for:

  • agile projects, that are on short order and do not follow the entire project lifecycle.
  • some projects that miss out on any security oversight upfront due to security team being very small and resource constrained.
  • projects that have no planned budget for security.
  • projects that undergo security oversight upfront, but due to lack of an enforcement process follow the delivered security requirements, security design and recommendations optionally.
  • projects that engage security late in the project lifecycle.

The methodologies for security services that I am proposing are geared towards fixing "what does not work" discussed in previous posts. These methodologies are in addition to the comprehensive security services that we already offer and are based on the following principals:

  • Providing value to the business i.e. help improve the security posture of a given project by providing easily consumable security advise.
  • Providing flexible security services inline with multiple ways the enterprise projects are executed.
  • Ensuring that the security oversight is provided to majority of the enterprise projects than just a chosen few
  • Partnering up with the business to get more weight on enforcement of security services and also making business security conscious.

The whole objective is to increase the reach of security to more projects, get more enforcement and ultimately provide value.

For example: if a small security group in an enterprise is only able to review 10% of the total projects due to resource constraints, it really doesn’t provide much value since 90% of the projects are getting deployed in production without any security oversight.

The goal is to automate some security tools to achieve baseline security at an enterprise level and still be able to offer premium services to critical projects. 

Business Threat Modeling a.k.a Business Misuse-case Development: 

In order to perform Business Threat Modeling the security services need to be engaged one step earlier than requirements stage. Yes am suggesting at the business case stage, wherein the business group writes down all the possible business use cases for a proposed project, that get handed-off to the IT group.

As a part of this threat modeling exercise, the security team reviews each business use case and writes a corresponding security misuse case as applicable. Then all of the security misuse cases which an application wants to prevent, are convert into business use cases (in a remediating language) and appended to the original list of the business use cases. 

This methodology achieves multiple objectives – 

  • The business group gets security aware and understands the non-technical business use cases very well. This helps the security team to get a buy-in on security objectives, which is really important considering business group is a client of IT and pretty much dictating everything for the proposed solution. This also ties into the principal, that since business owns the data for an application, it should be their decision to accept security risk or not, unlike in the real world where IT alone makes these decisions.
  • Irrespective of the security services being engaged or not in subsequent phases of project life cycle, the security objectives get embedded into the business use cases and eventually into the IT functional requirements that are developed based on business use cases. If security services are engaged then the security group can develop detailed technical security requirements as usual.
  • Business threat modeling is a service that can be delivered through short duration engagements, that helps agile projects to quickly consume security principles and not have any impact on their short timelines. This methodology allows to provide security oversight to more projects, which otherwise get missed due to budget , time and resource contents.

Baseline Threat Modeling a.k.a catching low hanging fruit or reducing the attack surface:

Again this approach is great when security cannot be engaged throughout the lifecycle of the project. Baseline threat modeling security service engagement works achieves the following  

  • To minimize the attack surface of an application/infrastructure component
  • To review various data flows through the architecture from security standpoint
  • To review the architecture and ensure basic security architectural controls are adopted
  • Ensuring corporate security policies/industry regulations are complied.
This review can be completed through short engagements by interviewing IT architects of the project when reviewing logical architecture of the solution and providing security recommendations in short order. This ensures the application go through basic security review before making it to production compared to no security review at all.

Build Reference Architectures for web solutions and embedding them into Corporate Security Standards/Policies: 

The basic security architectures for common web solutions like web services, SSO, web applications, portals can be templatized and still be generic enough to be customized by the IT architects for implementing a given solution.  Once these generic templatized architectural designs called reference architecture are completed, their use can be enforced through use of corporate policies and standards.

This would ensure standardized implementation of web solutions that have baseline security embedded in their architecture. This methodology aims at automating security oversight since now multiple projects can consume these templatized security architectures and be assured of having reasonable security posture for their application. 

To summarize, everything that is proposed here is inline with the attributes of "what works" discussed in my first post. Again the objective is to increase the reachability of security oversight across the enterprise, provide security services that are easy to consume for IT, and partner and communicate more with the business to help them understand the security posture of their business solution.

Usually, the security groups spend most of the time unsuccessfully trying to sell security advise to IT, when the real consumer for security advise is the business group for whom the security risk matters the most. 

In my next post for this series I will write about effective information security risk communication methodology, to be able to sell the security well across an enterprise.
Possibly Related Articles:
Enterprise Security
Information Security
Policy Management Regulation Information Technology Information Security Policies and Procedures Risk
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.