April 30, 2015

April 10, 2015

Please reload

Recent Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Featured Posts

Customer Q&A: How Do You Document Risk Assessments

January 5, 2010

Recently a customer asked me how to document risk assessments. Below is a summary of our discussion.

 

On the risk assessment documentation front, it depends. I like to define 3 categories of assessments:

 

1. Summary: for position papers and quick turn-around requests

 

2. Detailed: including hands-on attack and penn work

 

3. Enterprise: evaluate “project level” risks across the enterprise to support budgeting and portfolio prioritization

 

For summary or fast turn-around assessments: We called these Position Papers. A Position Paper is a one-two page summary assessment representing the one "voice" of the security team. It's used to quickly address a question from a team or executive e.g. should we allow personal mobile devices, which data should be encrypted on xx platform, or should we allow Facebook. Once a Paper is published, it's reuse saves an amazing amount of time. They're also a great resource when it's time to update official policies and standards (social networking anyone?).

 

We used a template and published on the team intranet. I'd like to post a generic template but I'm told to get some kind of legal disclaimer first. If you're interested before then, please shoot me a message. The primary element of the Paper is the inclusion of a well formed risk statement, similar to what's included in the Risk Communicator Help text. The form is very basic with a Title, Summary, Policy Reference, Risk Details (including current control effectiveness with evidence), Recommendation, References, Author, Approver, Status, etc. You can also use the Risk Communicator Heat Map image to add a punch to your Paper!

 

Of course the primary success factor is the process surrounding the tools. Here's how we used to do it. While any SME may author a paper, only certain managers may approve a paper. Having that “Draft” status really helps if the paper is leaked or when seeking input from affected parties. We had a one page workflow diagram and SLA agreement between the “approving managers.” This is key since each paper will represent the voice of the team. The CISO was also given the choice to be an approver or just informed of each paper. Once a paper is Approved, it resided on an IT Security intranet site. Any outside RACI party may also review and question the paper. However we didn’t open up to the whole intranet. Formalizing this process was a good team morale boost since it reduced FUD and minimized differing personal opinions. It was also a great opportunity for an individual contributor to present during an all-hands. I'll never forget how good it felt to receive the same question twice and simply forward a pointer to a Paper - priceless.

 

For detailed, multi-week assessments, the reports are much larger, their findings prioritized, mitigations identified, owners/timelines committed, and tracked in the GRC workflow process. Since this is old hat I won't bore you.

 

For enterprise risk assessments to support our enterprise risk prioritization and budgeting process, all the above and more is considered as evidence using Risk Communicator to prioritize “project level” risks across the enterprise. A project level risk is defined as a risk that may affect multiple assets and can be mapped to a mitigation project, so it's higher level than a specific vuln to an asset e.g. insufficient SDL for web development vs. xss in the ecommerce site. Of course back in the day we didn't have Risk Communicator, just a set of unruly spreadsheets and powerpoints.

 

Does anyone else use position papers? Share your thoughts on documenting risk assessment!

 

 

Share on Facebook
Share on Twitter
Please reload

Follow Us

I'm busy working on my blog posts. Watch this space!

Please reload

Search By Tags