A Checklist for Architecture & Design Review

Mostly the security requirements remain undocumented and is left to the choice or experience of the architects and developers thus leaving vulnerabilities in the application, which hackers exploit to launch an attack on the enterprise's digital assets. Security threats are on the rise and is now being considered as a Board Item as the impact of security breach is very high and could cause monetary and non monetary losses.

One of the key aspects of the IT Governance is to ensure that the investments made in software assets are optimal and there is a quantifiable return on such investments. This also means that such investment does not lead to risks that could lead to damages. Most of us are well aware that reviews play a key role in ensuring the quality of the software assets. As such, in this blog post, I have tried to come up with a checklist for reviewing the architecture and design of a software application.

While the choice of specific design best practice is interdependent on another, a careful tradeoff is necessary. For a detailed discussion on Trade off Analysis of Software Quality Attributes. Each of the checklist item listed here needs further elaboration and identification of specific practices, which will depend on the enterprise architecture and design principles of the organization.

Deployment Considerations

• The design references the security policy of the organization and is in compliance of the same.
• The application components are designed to comply with the various networking and other infrastructure related security restrictions like firewall rules, using appropriate secure protocols, etc.
• The trust level with which the application accesses various resources are known and are in line with the acceptable practices.
• The design supports the scalability requirements such as clustering, web farms, shared session management.
• The design identifies the configuration / maintenance points, and the access to the same is manageable.
• Communication with various local or remote components of the application is using secure protocols.
• The design addresses performance requirements by adhering to relevant design best practices.

Application Architecture Considerations

Input Validation

• Whether the design identifies all entry points and trust boundaries of the application.
• Appropriate validations are in place for all inputs that comes from ourside the trust boundary.
• The input validation strategy that the application adopted is modular and consistent.
• The validation approach is to constrain, reject, and then sanitize input.
• The design addresses potential canonicalization issues.
• The design addresses SQL Injection, Cross Site Scripting and other vunerabilities
• The design applies defense in depth to the input validation strategy by providing input validation across tiers.

Authentication

• The design identifies the identities or roles that are used to access resources across the trust boundaries.
• Service account or such other predefined identity requirements to, if so needed to access variuos system resources are identified and documented.
• User credentials or authentication tokens are stored in secure manner and access to the same is appropriately controlled and managed.
• Where the credentials are shared over the network, appropriate security protocol and encryption techniques are used.
• Appropriate account management policies are considered.
• In case of authentication failures, the error information displayed is minimal so that it does not reveal any clues that could make the credential guessing easier.
• The design adopts a policy of using least-privileged accounts.
• Password digests with salt are stored in the user store for verification.
• Password rules are defined so that the stronger passwords are enforced.

Authorization

• The user role design offers sufficient separation of privileges and considers authorization
• granularity.
• Multiple gatekeepers are envisaged for defense in depth.
• The application’s identity is restricted in the database to access-specific stored procedures and does not have permissions to access tables directly.
• Access to system level resources are restricted unless there is an absolute necessity.
• Code Access Security requirements are established and considered.

Configuration Management

• Stronger authentication and authorization is considered for access to administrration modules.
• Secure protocols are used for remote administration of the application.
• Configuration data is stored in a secured store and access to the same is appropriately controlled and managed
• Least-privileged process accounts and service accounts are used.

Sensitive Data

• Design recognizes sensitive data and considers appropriate checks and controls on the same.
• Database connections, passwords, keys, or other secrets are not stored in plain text.
• The design identifies the methodology to store sensitive data securely. Appropriate algorithms and
• key sizes are used for encryption. 
• Error logs, audit logs or such other application logs does not store sensitive data in plain text.
• The design identifies protection mechanisms for sensitive data that is sent over the network.

Session Management

• The contents of authentication cookies are encrypted.
• Session lifetime is limited and times out upon expiration.
• Session state is protected from unauthorized access.
• Session identifiers are not passed in query strings.

Cryptography

• Platform-level cryptography is used and it has no custom implementations.
• The design identifies the correct cryptographic algorithm and key size for the application’s data encryption requirements.
• The methodology to secure the encryption keys is identified and the same is in line with the acceptable best practices.
• The design identifies and establishes the key recycle policy for the application.

Parameter Manipulation

• All input parameters are validated including form fields, query strings, cookies, and HTTP headers.
• Sensitive data is not passed in query strings or form fields.
• HTTP header information is not relied on to make security decisions.
• View state is protected using MACs.

Exception Management

• The design outlines a standardized approach to structured exception handling across the application.
• Application exception handling minimizes the information disclosure in case of an exception.
• Application errors are logged to the error log, and the design provides for periodic review of such logs.
• Sensitive data is not logged as part of the error logs, but where necessary, the same is logged with appropriate de-identification technique

Auditing and Logging

• The design identifies the level of auditing and logging necessary for the application and identifies the key parameters to be logged and audited.
• The design considers how to flow caller identity across multiple tiers at the operating system or application level for auditing.
• The design identifies the storage, security, and analysis of the application log files

Why Software Product Delivey is not Identical to a Car Delivery?

I happened to sit in one of the project review meeting where client raised a question on software delivery expecting it to be used in production on the day of delivery by the vendor. He went ahead and started comparing it with a use case of a customer driving off a car upon taking delivery. I know all the project managers out there will jump in to say that don't compare apple with orange. On the one hand, yes, software development is unique and cannot be compared with production of a tangible product. On the other hand, attempts are being made by various standards organizations in helping the industry achieve a high maturity process capability and thus deliver production quality software consistently.

Software product vendors selling or licensing software products can however be compared to Car manufacturers. Take for example, Microsoft Office product suite, one can just go and buy it off the shelf and use it, just like driving off a car. This is possible for product vendors because, the product vendors over a period acquire enormous amount of knowledge on the targeted product domain and in turn subjecting it through as many cycles of testing before announcing its readiness.

A typical car from concept to production may take atleast few years and it would be in the order of around 3 to 6 years. During this period, the product undergoes various cycles of tests, which include crash test, drivability on the road conditions of the target market, etc. Similarly, software product vendors do conceptualize the product idea and then work on it over a period. The vendors are attempting to achieve a faster time to market, but by adopting newer product development methodologies. The one that works best is to identify the smallest piece of the software that can meet certain specific use cases and then build on top of it over a period of time.

In case of a software product, it is the vendor's responsibility to subject the product through various tests in production like environments before getting it out to customers. The tests include alpha and beta tests, where in interested end users are engaged to use it in production environments and collect the feedback on various aspects and the developers working on it to have all those critical issues addressed. Achieving a zero defect state may not be a possibility and vendors take balanced approach as to whether wait until all the identified issues be addressed or reach out to the market with certain known issues, which can be addressed in subsequent product releases.

But it is a different approach when it comes to bespoken software projects. The major challenges with the bespoken software projects that differentiates from software products include:

1. It is the Client who specifies the requirement. Though the vendor might facilitate documenting the requirements, it is the customer who formally agrees as to what need to be produced.
2. Lack of understanding and agreement on the non functional requirements, which are not documented in most cases.
3. The vendor might not be an expert in the target domain area. Though the vendor has expertise in the domain area, it is the customer's need that is final and not the vendor's understanding of the requirement.
4. The ever changing requirements. By the time, the vendor delivers the software, the requirements as agreed by the client would have undergone change due to various reasons.
5. It is difficult to unambiguously understand the requirements as the project progresses through various phases involving humans with varying abilities.
6. There are dependencies with various pre-existing or emerging software and hardware environments in the production environments of the client.
7. The client has the roles and responsibility to assume to make the project successful. However, it is for the vendor to ensure that the client understands their role and responsibility throughout project life cycle.

Another point to consider for this discussion is what constitutes delivery. A well written SoW (Statement of Work) clearly lists down the acceptance criteria, which when met would constitute acceptance of the delivery by the client. For a given requirements, no two vendors would build an identical solution. That's due to the tools, technologies out there for use and the varying intellectual abilities of those involved in building the software. It is important as to what the client wants, than how the vendor delivers the solution. For this reason, the client shall assume the responsibility of performing an user acceptance tests. Some times, the delivery of a software might mean implementation in production environment, which might involve data migration, appropriately configuring various pre-existing software and / or hardware.

In the end, it is all about managing the expectations of the client. It is not just setting at the start, but needs to be appropriately managed throughout the project life cycle.