Tutorials

Placeholder for category description of Foundations/Tutorials

OSA Landscape

In order to determine that OSA has the correct topic coverage we need to define the landscape for security architecture. That way we can identify topics that have poor coverage, determine priorities for new patterns, and help the community co-ordinate their activities.

In the perfect world there would be a classification for security architecture that we could adopt, but we do not know an existing potent slicing and dicing (do you?), and while the standards such as NIST, ISO and ISF divide their materials into chapters these do not translate into a security architecture landscape very well.

Therefore the two authors of this article dare to propose a landscape here, that we hope with the help of the community (that is YOU :-) can be refined over time to give a useful reference for OSA as well as the wider world.

Security Architecture Landscape

 

osa security architecture landscape components

 

The items in this landscape represent the major infrastructure and application architecture topics that keep IT departments busy.

V10: Updated landscape to include additional elements for greater coverage- Legal & Reg, Backup, Change Mgmt, Config and Asset Mgmt, extended Service Operations block, reorganised central security services

OSA Life Cycle

The OSA community has not yet decided on the primary reference model in terms of SDLC (Solution/System/Software Development Life Cycle).

The main requirements that influence the choice of the SDLC reference model are:

  • The model must have (at least and extension that offers) an adequate covering of security controls.
  • The model must be publicly available (without costly corporate membership rates)
  • The model must be used across several industries/countries
  • The model must NOT be driven/owned by a single company (e.g. vendor)

The currently considered models are:

  • ISO/IEC 15288, System Life Cycle Processes
  • IEEE STD 1220, Application and Management of the Systems Engineering Process
  • ISO/IEC 21827, Systems Security Engineering Capability Maturity Model (SSE-CMM)
  • ITIL
  • COBIT

The above listed models represent a very wide range of model types and hence it maybe difficult to compare against each other.

Please contribute your experience via This email address is being protected from spambots. You need JavaScript enabled to view it..

The definition for the term SDLC framework is (as listed also in the glossary page): An SDLC framework defines on a high abstraction level which processes are needed to achieve a given set of system qualities. It hence also defines the actors and puts the SDLC processes into the context of related processes (like project management, architectural governance, etc).

Writing a Control

Placeholder for "writing a control"

OSA Actors

In OSA patterns we refer to a number of generic roles, we call them actors. To ensure the consistency between the patterns we collect the description of these actors centrally.

The definition for the term actor is (as listed also in the glossary page):
"An actor is a prototypical business role. In an attempt to create a simple actor model, aspects of different business roles can also be combined into one actor. OSA patterns visualize with actors, the set of responsibility that can be assigned to a prototypical role, in a given setup."

Click on the preview picture to download the current draft of the actor model.

 

Before establishing the above actor model we were evaluating whether there are other reference models that could be used. The evaluation of the potential reference model was subject to the following requirements:

  • The model must have security relevant actors
  • The model must be publicly available (without costly corporate membership rates)
  • The model must be used across several industries/countries
  • The model must NOT be driven/owned by a single company

Our evaluation shoed that the following models could have been taken as a reference:

Please contribute your experience via This email address is being protected from spambots. You need JavaScript enabled to view it..

Writing a Pattern

Step 1- Prepare and Research

 

Choose pattern topic

Decide on the pattern you are going to tackle.

  • What OSA area will the pattern be part of? (see OSA landscape)
  • What use cases do you want to cover?
  • Has anyone else started to address this area? (check our Google Groups page)
  • How wide will you make the scope?

It's best to discuss and seek advice at this stage before dedicating time to writing. A draft pattern takes at least 8-10 hours to put together, assuming you are fairly expert in the given field. This increases dramatically if you are trying to work in an area where you not a subject matter expert. Most patterns need a further 4-5 rounds of revision before they stabilize and reach a suitable quality level.

Reserve pattern number

Post into the thread to reserve the next free pattern number from the OSA forums making sure you specify the pattern you will be writing. 

Get the latest templates

Download the latest templates and icon packs. Extract the icon pack, the standard pack includes SVG and PNG, but you should only use the SVG versions for creating your pattern (we may drop PNG from future release to avoid confusion).

Extract the pattern template pack. The standard pack includes:

  • SVG visual pattern template that will be used to create the pattern
  • Open Office pattern template which should be used to record the attributes, and where the SVG will be embedded (this may not be needed any more?)
  • HTML pattern template which records the same information as i) and ii) and allows us to port the pattern to the website
  • list of controls in HTML format, so you can more quickly build the html version of the pattern by pasting the appropriate control hyperlinks.

Rename the files to the naming convention YY_MM_vv_Pattern_XXX_NAME where YY_MM is major release e.g. 08_02, vv is version starting from 01, XXX is the next free pattern number e.g. 006, and NAME is the descriptive name of the pattern e.g. Wireless_guest.

Research pattern topic

Research the pattern and collect references. You may want to check NIST who have a lot of excellent reference materials. Often vendor sites such as MicroSoft, CISCO and so on will all have useful reference materials. Security specific sites such as SANS, ITSecurity, OWASP and DarkReading may help. Consider checking vulnerabilities for the area you are researching with sites like Secunia. Any authors or materials that inform your pattern on should be credited with the appropriate links. You should not plagiarize materials under any circumstances.

The following prompts can help to author the pattern:

 

  • Usage scenarios: how will the pattern be used.
  • Threats: Consider the threats that you are trying to mitigate.
  • Efficiency: Consider which controls are expensive or hard to implement.
  • Best practice: Think what good looks like for the problem you are trying to solve, and relative to the industry you are in.
  • Wisdom of the crowd: Post thoughts and questions to the bulletin board.

The core team find it useful to let a pattern rest for a while and look at it with fresh pair of eyes after a few weeks. The collected information should be distilled into the HTML pattern wrapper.

 

Step 2- Design and annotate diagram

 

Design the diagram

Now it's time to construct the visual pattern using Inkscape. Generally it is easiest to start constructing the pattern by populating the modules you will use into the SVG template. This way you can quickly build up the basic components and inherit the majority of controls you will need to reference. Open the SVG template and note that you already have all controls included with predefined hyperlinks. This allows you to quickly cut and paste to annotate your pattern. Use the import function [File|Import] to bring in SVG icons or parts of other patterns. Consider how the modules will connect and lay them out on a Inkscape document of 780x780 pixels [File|Document Properties], so that it the reader can naturally follow the flow. It preferable to follow a left to right or top to bottom structure.

Annotate the diagram with controls references

Add references for controls used in your pattern to the HTML wrapper, these are available from the HTML controls template in the library.

 

Step 3- Review and publish

 

Review in Bulletin Board

Upload your pattern and HTML wrapper into a new thread in the pattern section of the OSA forum for review. Monitor feedback for 2-4 weeks, incorporate suggestions as needed.

Publish to library

Ask one of the core team to publish into the pattern library. Email This email address is being protected from spambots. You need JavaScript enabled to view it.

More Articles ...