Microsoft Security Risk Management Guide - Worth a look?
The Security Risk Management Guide by Microsoft assists to place a plan for security risk management. This guide is technology agnostic and references many industry accepted standards for managing security risk.
Sphere: Related ContentDebugger and Sandboxes in Windows
It is not always possible or desirable to set up a Virtual Machine for debugging an application. While useful, it can be boring to work within a VM, and on the other hand it can become an useless complexity. However, you need administrator’s privilege to debug (seDebugPrivilege turned on). And this means your debuggee will run as administrator too. So? In Windows XP, a good solution is to perform a full sand-boxing of the Debuggee, but there are other solutions too.
One is to make the debuggee and the debugger run on different accounts. So, the debugger runs as administrator and the debuggee as a limited user.
A limited user cannot install drivers, alter executables, Windows stuff, and better- it stays away from our private document folder.
Yes, but how obtain this? A simple yet effective solution is to hook the function responsible for launching the debuggee, and force it to start under another account.
Sphere: Related ContentHow secure is SSE-CMM?
Let us cite from the SSE-CMM website:The SSE-CMM (The Systems Security Engineering Capability Maturity Model) [1] describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering. The model is intended to be used as a:
- Tool for engineering organizations to evaluate security engineering practices and define improvements to them.
- Standard mechanism for customers to evaluate a provider’s security engineering capability.
- Basis for security engineering evaluation organization (e.g., system certifiers and product evaluators) to establish organization capability-based confidences (as an ingredient to system or project security assurance).
Insecure SPICE?
As process engineer I have been recently part of an SPICE (ISO/IEC 15504, Software Process Improvement and Capability dEtermination) assessment [1]. What SPICE is concerned about is the capability provided by the organization’s management and process definition structures. SPICE is not a methodology. Although SPICE sets out a list of activities that might (and should) occur in a software project, it does not set out the order in which such activities should be carried out.
The lack of SPICE is that it is defining processes in process dimensions divided into the five process categories of:
- customer-supplier
- engineering
- supporting
- management
- organization
Since SPICE should be a framework for the assessment of software processes, I asked myself where the processes for the development of secure software are hidden. We should not lcoate it at the customer-sipplier or organizational processes.
In my opinion it should be at least one touch point for the engineering (secure cocde development and QA), management (guidelines) and supporting (patch creation) process domains.
However, this point is missing compared to CMMI [2] efforts. The model SSE-CMM (Systems Security Engineering Capability Maturity Model) describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering [3]. More about SEE-CMM and its real capabilities in an upcoming blog entry.
References
[1] http://www.isospice.com/
[2] http://www.sei.cmu.edu/cmmi/
[3] http://www.sse-cmm.org/