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

Risk assessments for application software is not a matter of a quick penetration test nor a matter of code reviews at a single point in time. It is a process of moving through the application/solution’s Software Development Life Cycle (SDLC) and evaluating the results of the controls that are put in place at each phase. Whether it is waterfall, or agile method, waiting for the end of the final delivery of the software makes no sense. No matter how much you put into the end phase (usually the acceptance testing), if you have not tested and sampled the effectiveness and examined the results of the controls along the way, it will be a flawed product. So having a security risk gate review and assessment at each point in the process must be mandatory.

The needs and the controls will be different at each point in the SDLC for a security evaluation. The previous posting spoke of the necessary elements of scope, purpose, objectives, responsibilities, and processes for a risk assessment. will be different. While an application security is evaluated on many different levels, from code to architecture, the intent is to define “risk assessment” on the latter since that is within the scope of responsibilities for an application security architect. (More on the role of that architect during the detailed specification, development, testing, and deployment/operational phases of the SDLC in later posts).

The last post mentioned “vectors” (my term!) for classification. Perhaps, it can be better explained as four areas of vulnerabilities, and each will have, assuming this morphs into a procedural process some definition of administrative, physical, and technical controls and data-gathering. I would propose the following classifications:

Digital Identity: The application as well as the end-users will be using a defined set of information (credentials and the resulting authorization and specific attributes) in order to operate in the defined environment. The setting of the privileges as well as the placement of information is reviewed. This is typically expressed as the authentication and authorization data model

Access Management: The application needs to allow access to its end-users for data as well as access data on its own. This defines what access scenarios need to be used and how they are used, as well as indicating the type of information that will be exposed, either singular or composite (for data leakage) as well as validated. At a minimum, a data model and sequence diagrams are used.

Identity Management: This addresses the operational impact (people, process, technology) to manage the digital identities across the enterprise, or, in the case of federated identities, across multiple domains. If the security infrastructure (roles, delegated administrators, governance, enterprise policy, data owners, etc) is affected, this brings out the issues. References are made to both of the data models and additional definitions are provided for entitlements and roles.

Session Management: In addition to the typical state (and perhaps the timing) diagrams that developers are prone to use, this addresses the concerns of “data in use”, “data in motion”, “data at rest”, and “data disposal” throughout the software solution’s data life cycle and transaction flow, either batch or “real-time.” One should not confuse, in this pattern definition that of an access “session”, which is the interaction of end-user to system (or system to system), with that of data life-cycle sessions of data in points in time.

Each of these classifications or vulnerabilities could have a varying set (some overlapping) of threats based upon the threat model. Basically, we are addressing a set of security aspects and focusing on a set of possible attacks. But rather than listing the attacks and referencing the method to reduce the risk for each classification (incident based), we will look at providing a checklist or asset based methodology for each of the classifications.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect