Road Map for an Application/Software Security Architect (Part 2)

Vulnerability testing at the acceptance stage of an application’s Software Development Life Cycle (SDLC) will not compensate for the lack of an understanding of what is being done during the software development even though you may not have control over the development efforts. You need a plan that puts those controls in place and allows that governance. Ignoring vulnerabilities will not prevent breaches.

Remembering back to building a risk assessment plan, we can build a similar plan for application security, but with the intention of engagement at predefined points in the SDLC for _every_ software solution (or application) that might also raise concern for a risk assessment. The application security plan needs to cover the same set of tasks that a risk assessment might cover and would have a similar set of assignments of a RACI (Responsible, Accountable, Consulted, Informed) matrix.

The first step is to establish the purpose and objective of the program. The program’s main purpose is to reduce the number and level of “bad” design and application programming habits. The intention is to determine the effectiveness of the plan by measuring how effective it is in avoiding mitigation efforts. This assumes that there are appropriate policies as well as “tone at the top” in place (or else this becomes the first and most significant prerequisite prior to organizing the plan). But that does not answer how to measure the effectiveness. Partially, a baseline evaluation of the history of solutions and applications previously submitted for risk assessments, and the results obtained, especially, if any further effort was required for mitigation is needed. Having never performed a defensive risk assessment before, it is easy to miss the “unknown knowns”, so part of the object of the program will be to identify what has been “missed”.

The second step is to establish the responsibilities for this plan The team that is responsible for the development of the plan may be the same team, or designates, that will be responsible for implementing the plan. While on the surface this may be a pure technical “play” (let the architect’s handle this!), in reality it is a cooperative effort that involves input from the business users (or at least the ones that are the most involved in development of the significant services), the security officer (and the team that does the current risk assessments), the audit and controls types (for advice) and the application architects. Involved in this process will be senior management since it should be fully expected that the SDLC process will be affected: you will need a Security Review Board (SRB !!) to intercede at various points (gates) of the SDLC.

The process entails the identification and classification of the assets, which need protection because they are vulnerable to threats. But in this case, we will not need to assign to the classification a priority or an impact value, but an assigned standard (or guideline) in which to measure the effectiveness in meeting the classification. In an application assessment, the primary asset is “data” to which we assign vectors that would impact the security (and privacy protection) of the data. We will evaluate the vectors in the light of the threats and the vulnerabilities that it might expose.

In this plan, we are addressing the identification of the exposure and how to handle that exposure, either through a certain set of standards and guidelines that would be from a library of information and documented experience. Obviously, this library would grow with the repeated iterations of additional projects. The intention is to drive the knowledge of the appropriate behavior of applications in regard to security to the application architects and detailed designers from the security architect and the security team.

Next post … identifying the classification of vectors

Steve Primost CISSP, CISM
Information/Application Security Architect

Road Map for an Application/Software Security Architect (Part 1)

With the level of security concerns about security, it is interesting that there is not more concern with a holistic focus on application security. Numerous articles are citing chilling statistics about security breaches, with the majority (some use the figure of 80%) being related to applications. It is not for lack of information as to what constitutes an “application problem”. One just has to go to the OWASP web site for more than sufficient information.

The issue, as I see it, is much more than the “what” and “how”, it is the approach that needs to be defined (and understood) as well as the “top ten”. In this, and the following series of posts, a modest proposal for a logical approach that would address the issues of how to define a secure application architecture (the plan), what would be the logical framework (the organization), what would be the steps that both the supplier (the application security architect) and the consumer (the software developer) would take to implement (the direction), and how would you assess the cost and effectiveness (the controls).

The basis of any security plan is that it must consider the threat model. In elementary form, it merely states that you can determine a set of possible attacks with a probability of occurrence to a set of assets that have a value worth protecting. So one needs to build a set of countermeasures to mitigate the effects of the threat that could exploit the defined vulnerabilities. It is considered “best practice” to define a set of threat models for, in this case, an application solution, so that the larger problem is reduced to a manageable set of smaller problems. This is the approach we will take as we course our way through the road map.

Clearly, there are two ways to approach the determination, and ultimately, the use of the threat model. Only when you use both will you have confidence that you have completely address all of the threats.

The typical approach seen in organization today is that of the reactive mode (some sources might use the term adversarial). The Software Development Life Cycle (and choose any one of a number of types) grinds forward with security, more or less, part of the “development” and “design” until the test and acceptance phase. There may have been some meetings to review the risks associated with the application solution, but the real crunch comes when the code is delivered. The security group gets involved and performs a true risk assessment, with both penetration and vulnerability testing at all layers. Vulnerabilities may be detected, assessed, and, if significant (cost-justified), a process of risk mitigation is planned and completed. The question is, in my mind, whether you really did address all of the threats and applied the appropriate controls or you went through an exercise in compliance. But compliance is not security!

The alternate approach gaining acceptance in a number of organization, perhaps for the savings in development cost, is that of the defensive mode. If a good security strategy is that of “defense in depth”, then apply it to the development cycle, and address the separate layers of development specification. Rather than the “gate review” for the security “check box” as the security architect judging the development architect, view the development architect as the security architect to work within the technical specification framework. With a set of standards, guidelines, templates, and training of developers, security become part of the logical architecture, reassessed when the review of the physical architecture is done, incorporated in the detailed design, and instantiated in the software. Now the evaluation of the acceptance of the software, which would include the penetration and vulnerability testing of the traditional (reactive) approach above, but would add the additional dimension of understanding the development view.

Steve Primost CISSP, CISM
Information/Application Security Architect

Windows Server 2008 R2 Recycle Bin (Part 1)

Had a very interesting conversation about the new Server 2008 R2 version. Most IT admins know it’s been updated with new features, and the one question that usually comes up is- “Doesn’t this mean I won’t need third party apps?”
Well, no, you still do. Really. For example, let’s look at one of these new features, the Recycle Bin.
Remembering the basics:
-Deleted objects in Active Directory aren’t deleted immediately
-Marked with a “tombstone” flag- replicated to all DCs
-Tombstoned objects are saved for a while – 180 days by default
– When deleting objects, Active Directory removes most of its attributes
Windows Server 2008 R2 introduces this change to the deleting process: It places your objects into a “deleted” state where their system attributes are left intact (non-system attributes are stripped out). Recovering an object (changing the tombstone flag) is made easier AS LONG AS THE OBJECT EXISTS IN THE TOMBSTONE.  Following the default 180 days in the tombstone, if no changes are made the object becomes “recycled” and its attributes are stripped out, so it can no longer be recovered.
So this should be very easy right? Well, if you’re trying to access a deleted object with your native management tools you can’t, even with all the changes in Server 2008 R2. Recovery is still not an easy task. Despite the name, you won’t see an AD “Recycle Bin” on your desktop or in any other directory. You’ll have to continue using low level directory editors, scripting or other more complex ways of recovering (reanimating)objects from their “deleted” state. Oh, and by the way, you CAN’T use this new feature until every DC has been upgraded to this new version of Windows (Server 2008 R2 specifically).  What does this mean to you? You have to:
– Upgrade every domain you have to the Windows Server 2008 R2 functional level
– Upgrade your forest to the Windows Server 2008 R2 functional level
(more on this in Part 2)

CionSystems Releases New Version of its Active Directory Manager Pro

We released the newest version of its application, Active Directory Manager Pro, which works with Microsoft Windows Server® 2008 R2 to offer customers enhanced security, as well as innovative user interface features and reliability improvements. The Active Directory Manager Pro is an affordable and comprehensive web-based application that greatly improves and automates User Provisioning, Deprovisioning and AD management. Managers can view, approve changes, and manage the full user lifecycle, along with automating tasks and generating reports on the Active Directory environment without using any scripts. Making our application compatible with Microsoft Windows Server 2008 R2 helps us offer our customers compelling benefits, including lowering TCO for Windows Server and AD administration, and improved security.

Removing Windows SharePoint Services 3.0

As Sharepoint becomes mainstream, sometimes is nice to remember the little things. Recently we had a case where we had to do just that. We removed Sharepoint Services 3.0 and reinstaled it, only to notice the same info on the webpage. We did a little digging and came across an article from Microsoft pointing out that when removing Sharepoint Services 3.0, you have to manually remove the Windows Internal Database. With this version, there’s no way to remove it through the GUI and no user notification, so you have to use the msiexec.exe command to do it.
If you are running an x86-based edition of Microsoft Windows Server 2003, use the following command line to remove Windows Internal Database from the computer:
msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB}
CALLERID=ocsetup.exe

If you are running an x64-based edition of Windows Server 2003, use the following command line to remove Windows Internal Database from the computer:
msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01}
CALLERID=ocsetup.exe

The full Microsoft article (KB920277) can be found here.

Group Policy Settings References for Windows Server

Microsoft policy settings for computer and user configurations included in the Administrative template files delivered with the Windows operating systems specified. You can configure these policy settings when you edit Group Policy objects (GPOs).
These spreadsheets include the following categories of security policy settings: Account Policies (Password Policy, Account Lockout Policy, and Kerberos Policy), Local Policies (Audit Policy, User Rights Assignment, and Security Options), Event Log, Restricted Groups, System Services, Registry, and File System policy settings. The spreadsheets do not include security settings that exist outside of the Security Settings extension (scecli.dll), such as Wireless Network extension, Public Key Policies, or Software Restriction Policies.
http://tinyurl.com/ljxtvn