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

Real Time Event Notifications

IT admins don’t want small problems to snowball into an issue that can cause severe damage to a company’s infrastructure and Active Directory. They need a robust alert mechanism which identifies any threats in REAL TIME.  Most IT organizations are unaware of the changes until something breaks. This leads to downtime, loss of productivity, and higher cost. Becoming proactive and more aware is part of the overall IT optimization strategy.
Consider this scenario: An administrative account in Active Directory has been hacked or accessed by someone with malicious intent and you as the administrator of the network are not aware. Logging into an administrative account is an activity that is very critical and ignoring it could result in irreparable damage to your network security.
A reporting solution while outlining what happened and when, will do so after considerable time has passed, when it could be too late to be acted upon. The usual audit solutions will help you outline and analyze who made changes to what- after you’ve discovered the damage. What is needed is a proactive approach to AD security- a product that will let you know Who made What changes When and Where, in REAL TIME.  For such a product to work accurately, it cannot and should not rely only on Even Log information. The most reliable info is in Active Directory. The best solution in this case is to pull the data from both. Other changes in Active Directory might not necessarily require an administrators’ intervention, so adequate filtering is also needed.
Unmanaged changes are a problem in every company. They are THE primary cause of outages. If they are not prevented, the company will fail a security audit. However, even planned changes should be monitored to ensure that policies are being followed. Active Directory Change Notifier allows IT administrators to configure (define) alerts for one or more desired Active Directory events. Any alert is then delivered to the mailbox of intended recipients.
Active Directory Change Notifier is a flexible, scalable, easy to use application that will help you with your day-to-day activities. This application is part of our Active Directory solutions that are designed to simplify your IT environment and enable you to work better, faster, and more efficiently.