Last Updated: 2012-10-17 18:56:27 UTC
by Rob VandenBrink (Version: 1)
A word that I'm hearing a lot these days from clients is "Risk". And yes, it has a capital R. Every time.
Folks tend to think of any risk as unacceptable to the business. Every change control form now-a-days has a Risk Assessment and Risk Remediation sections, and any issue that crops up that wasn't anticipated now becomes a process failure that needs to be addressed.
Don't get me wrong, I'm all for some rigor in Risk Assessment, but every risk can't be an 11 on a scale of 1 to 10. Enter "ISO/IEC 27005:2011 - Information technology - Security techniques - Information security risk management".
ISO 27005 allows system administrators (change requestors) and managers (change approvers) to use a common approach, the same language and come to an agreement on risk. Most importantly, this helps parties like this come to an agreement quickly – if you’ve ever had a change approver who has trouble saying either “yes” or “no”, you’ll understand why this is so important.
This standard starts by defining a framework and a flowchart to manage risk (below). Like all good methodologies, there’s decision points and iteration, so you’ll need to ensure that you identify decision makers who will actually decide, or you’ll never escape!
Once “inside” the flowchart, I found that I was impressed with the emphasis on business and organizational language – this standard is written to get buy-in from management (this is a good thing).
They’ve also got the obligatory section on qualitative and quantitative risk, but more importantly, in the appendices there is some clear direction on how to use both approaches. More importantly (in my books anyway), they have examples of taking a qualitative assessment and quantifying it, allowing you to apply numeric values to “fuzzy” situations. This makes the job of the System Administrator easier – when proposing a change, you can use this approach to assign actual values to things,
The Risk Treatment section ensures that a final decision is made. Too often we see managers “decide not to decide” – following this standard ensures that everyone understands that this is not an option - there are a few choices to make, and yes, assuming the risk is a valid choice. When all the ducks are lined up and it’s decision time, then a decision there will be!
I can’t cover every aspect of a 68 page standard in 1 page, but suffice to say that this one is well worth the purchase price – yes, it’s an ISO standard so you’ll have to buy it to use it.
If you've got a "risk management" war story, or a comment on this post, please use our comment form, we'd love to hear from your!
In SANS SEC579, we use the ISO 27005 methodology and apply it to the ENISA Cloud Risk document (see references below) to contrast the risks of Public and Private Cloud deployments to your organization.
(2011). ISO/IEC 27005 - Information technology - Security techniques - Information security risk management (ISO/IEC 27005:2011). Geneva, Switzerland: International Standards Organization
(2009). Cloud Computing: Benefits, risks and recommendations for information security. Crete, Greece: ENISA - European Network and Information Security Agency.
Last Updated: 2012-10-17 03:19:56 UTC
by Mark Hofman (Version: 1)
Oracle has just released their critical patch update http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html
Quite a number of products are being patched also for those of you subject to PCI DSS there are a significant number of patches addressing issues with a CVSS score of 4 or higher, which must be patched under the standard.
They have also released a critical patch update for Java http://www.oracle.com/technetwork/topics/security/javacpuoct2012-1515924.html
The info in the Oracle bulletin is comprehensive and should allow you to identify what needs to be done fairly easily. Both bulletins have the following wording in the work around section "Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply CPU fixes as soon as possible." For most of us not new (at least not on the java side), but maybe a strong argument if you get pushback on patching.
Happy patching, as always test before you implement.
Mark H - shearwater