Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

1. Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
2. Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
3. If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
4. Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
5. Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

·         All final threat models for future reference.

·         Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

·         All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

·         The final symbols that reflect the product shipped should be archived.

·         The Final Security Report and project signoffs to validate your security audit activity

·         Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

We represent situations in the domain of event processing by building and refining models of situations. This means that one way to develop CEP applications or designing CEP architectures is to define situations of interest and build models that define the situation.

After we have a working model of the situation we will generally have a hierarchical model of the situation composed of various components of the situation. For purposes of discussion I refer to this as situation modelling.

If a situation is modelled with 15 components then we need to detect these components of the situation. In addition, it is generally not good enough to simply detect each one of these components of the situation. We also have to hold the state of each one of the situational components.

However, it is not good enough to simply observe the state of 15 components of a situation in the detection process; we also need to observe the relationship between the components.

So, let’s say the situation we are looking for is “commercial air plane collision” and we are building a model of this situation. To keep the model simple we will limit the model to airplanes and omit objects like birds, buildings; but we will include wind, air speed, and direction.

Our situational model consists of primary objects, in this case an airplane. Now we need a simple model of an airplane, which is modelled, in this overly simple example, as span, velocity, acceleration, altitude, orientation and relative wind speed and direction. Generally, an object-oriented approach to model building is preferred so we can reuse the model and overload, morph, inherit and encapsulate as necessary.

One example would be when our boss comes to us and says, great job on the airplane collision model, but I also want to know how much jet fuel is on the planes at the moment of our projected situation, so we can estimate the intensity of the explosion. So we need another model and our earlier very simple airplane model would inherit the jet fuel tank model our boss requires.

I hope from this simple example of model building that you will conclude that modelling is one of the most important aspects of CEP. Without good models, situation detection impossible, and CEP engines are useless. Situation modelling is critical to CEP.

So, if a CEP vendor comes to you and says they have a very powerful CEP engine, ask them to show you a complex model of a situation that is important to you and explain to you how they represent the object. If models are not represented using an object-oriented approach, I recommend you send the vendor back to their software development lab, because without an OO approach to modelling, you can only represent very simple situations.

Furthermore, let’s say you are leading a team building a large model. If there are several teams working on various parts of the model, you need a common framework to integrate the work of the various teams. I strongly recommend an OO approach to your model building systems architecture and work breakdown structure.

In a future post, I will write about the companion to modelling – simulation

Today I noticed that SL Corporation has revamped their website with a new page, Solutions for CEP Engine Users.    The page is well written, reinforcing some of my earlier posts on the value proposition for CEP; so I hope the folks at SL don’t mind if I repost their excellent thoughts on BAM and CEP here. 

Solutions for CEP Engine Users by SL Corporation

© 1999-2008 Sherrill-Lubinski Corporation. All rights reserved.

Complex Event Processing (CEP) is a relatively new technology that is used to help companies detect both opportunities and threats in real-time with minimal coding and reusable key performance indicators (KPIs) and business models. Just as services are shared and reused in a SOA, CEP permits the sharing and reuse of KPIs in business activity monitoring while efficiently processing events so businesses can act on situations that impact business and take advantage of real-time processing.

Business activity monitoring, often referred to as BAM, is the capability that Gartner and other distinguished analysts use to describe this visualization capability in the business world. BAM introduces a human element to CEP. It is well-established that the human mind is, today and for the foreseeable future, far superior to machine intelligence in making sense out of complicated situations and events. Therefore, BAM is critical to the success of any complex event processing (CEP) solution.

Depending on an organization’s mission, BAM can be used in various levels within an event processing solution to help users visualize and understand the dynamics behind rapidly changing situations and critical business events. In other words, BAM plays a key role wherever there is a need for better insight into the myriad events that effect your business operations.

BAM provides real-time visualization and alerting capabilities for users to better understand how business events impact their organization. BAM software permits users to quickly prototype, build and deploy event processing business solutions. For example, a telecommunications company would find BAM useful to achieve event-driven SLA monitoring and management; and a large retailer would find BAM important as they stay on top of business-critical events in their supply chain.

Insight gained from BAM, in concert with event processing solutions, enable organizations to make better and faster business decisions so they can rapidly sense and respond to threats, problems and opportunities. BAM solutions permit applications to be designed, deployed and modified rapidly with minimal or no coding resulting in significantly lower development costs. Therefore, a key benefit of BAM in real-time event processing solutions is that KPIs can be deployed, monitored, revised, reused and utilized, economically and rapidly.

Depending on the business application, BAM-enabled visualization is required at numerous levels in an event processing architecture. For example, events from across the enterprise are typically processed by a CEP software platforms from companies such as TIBCO, BEA (soon to be Oracle), Progress Apama, StreamBase, Aleri, and Coral8.

Long before KPIs are displayed to the business users, BAM tools can be configured to assist application developers to monitor and visualize the raw event stream. For the developer, their business is developing applications, and BAM can be very useful when designing KPIs for event processing applications.

Fine-tuned KPIs that have been derived from an event processing application are displayed to the business user. These KPIs can indicate risks, threats, problems, opportunities and other emerging business situations that impact the business.

BAM, in concert with state-of-the-art event processing software, provides the framework for a complete sense-and-respond capability for businesses. Processing raw events and event streams for business opportunities and threats requires robust and rapidly deployable visualization solutions. This is the reason that many distinguished analysts believe that BAM and CEP are complementary and critically interdependent core business capabilities. We at SL Corporation agree, and are pleased to be the leading BAM visualization platform in the event processing/CEP ecosystem today.

© 1999-2008 Sherrill-Lubinski Corporation. All rights reserved.

The other day I discussed CEP in Layman’s Terms: Reuse and Agility. Today, our topic is CEP and transparency. One of the major benefits of “white box” event processing solutions is transparency, something not readily available or obvious in black-box solutions.

Friend and colleague John Bates, Progress Apama, often discusses the benefits of white-box algorithmic trading platforms in terms of increased time-to-market and other competitive advantages. I agree with John and would like to point out that there is another key benefit, in simple layman’s terms, transparency.

For example, let’s say you have designed an event processing solution for operational risk management (ORM). It is time for your favorite auditors to come by and they wish to take a look at what is going on with that proprietary black-box ORM applications running quietly in the server room.

The nice auditors ask you, “What does that application do?” and you reply “Well, it looks for evidence of insider trading,” and they ask “Do you mind if we ask how?” and you respond “Good question, do you mind to wait a moment while I get you the contact info for the vendor because we don’t have access to the source code or the actual key indicators (KIs)?”

Now, let’s look at the white-box scenario:

Again, the nice auditors ask you, “What does that application do?” and you reply “Well, it looks for evidence of insider trading,” and they ask “Do you mind if we ask how?” and you respond “Yes, sit down and we will pull up our insider trading key indicator models. These models are stored in XML format and viewable in our graphical KI design studio. We can print out the KI models for insider trading if you like!” and the smiling auditor says “Thank you, your system is much more transparent than the last place we visited!”

This scenario also applies in looking for why certain KIs were not detected that should have been; or when performing a root cause analysis to see why the KI you used in your wrong business decision was inaccurate.

So, CEP in layman’s terms is what we might refer to as the ART of event processing:

• Agility
• Reuse
• Transparency

Please feel free to reuse these idea, but please don’t forget to reference the author and this blog

Kindly share and reuse by reference, because all content in The CEP Blog is ©2007-2008 Tim Bass - All Rights Reserved. Thank you!

We often hear a lot about the core benefits of SOA, which include reuse and agility.

This week, I was in a meeting with Manoo Ordeedolchest, Board Member of Software Park, Thailand, Former President of the Software Industry Promotion Agency (SIPA), Former Dean, The School of Technology, Shinawatra University and a Lecturer at Chulalongkorn University, National Institute of Development Administration (NIDA), as well as other universities. 

We were discussing CEP and our proposed CEP Center of Excellence concept for Software Park.  One of the topics we touched upon today was CEP “in layman’s terms.”    After some brainstorming about CEP, it we were moved to draw a parallel between the SOA and CEP concepts of IT agility and reuse.

Just as SOA is centered around service component reuse and the agility to create new applications from service components quickly and economically; CEP can be considered to be centered around the reuse and sharing of domain knowledge, key indicators (KIs) and other intellectual property (like analytics) when processing events.

In an SOA, we modularize services and a service-component architecture in order to share services and build new applications from these service components.

One of the business goals of CEP is to modularize and standardize declarative programming logic and reuse this logic with event processing platforms from a variety of vendors.    This permits both reuse and agility when building event processing applications, at the application logic level versus the SOA service component level.

So, in laymen’s terms CEP can be discussed using the same SOA concepts of reuse and agility, applied to event processing application logic and KIs.

In a future post, I will talk about about CEP and transparency in layman’s terms.

As I promised, I will post another blurb on log standards following the first: Who Benefits from Log Standards? Part I - Log Management Vendors

Just as the previous one, this comes from the still-upcoming CEE whitepaper (yes, official website is still upcoming as well). Here is the quote that covers the benefits of log standards (in this case, CEE):

"Event Producers (vendors & products)  [A.C. - i.e. platform and application software vendors as well as network gear developers whose products generate logs] will be able to decrease cost associated with logging and reuse log libraries. Vendors could move away from encouraging developers from picking log messages on a closest-fit basis from a limited, product-specific message index. Furthermore, the generation of these log messages could be bases on a single API call. Also product interoperability will increase with the others who speak with the same event expressions, resulting in satisfied customers. "

So, in other words, it is not only the  log management people who will benefit: software vendors will have an easier life with logging; this applies even more to smaller vendor and even in-house IT teams who often (always?) struggle with how to do logging right in their applications ...