Sunday, July 20, 2014

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.
  • 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.
  • 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.
  • 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

Sunday, June 29, 2014

Governance of Agile Delivery


The Agile methodology brings in alternate approach to traditional project management, where success was hard to get. Typically used in software development, Agile methodology help businesses respond to unpredictability. By focusing on the repetition of smaller work cycles as well as the deliverables, agile methodology is described as “iterative” and “incremental”. In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development viz. requirements, design, etc. is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to change course. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released. Considering the value delivery that the Agile methodology promises, its adoption has been on the rise and today most organizations, including Government are embracing Agile approaches.

Governance of Agile Delivery

Critics say that Agile methodology is all about working in an unstructured way and for that reason, they believe that governing agile practices is always a challenge. While some of the Agile principles appear to support such criticism, there are many cases where organizations have successfully implemented processes and frameworks towards governance of Agile practices. Agile practitioners believe that because the agile methods are designed to be self-assuring, when practiced right, there exists built-in governance and accountability.

More so, the agile practices are more collaborative and operates continuously, requiring the stakeholders to review and test the deliverables on a continuous basis and helps the team to take alternate course of action as may be needed. Collaborative culture helps resolution of problems quicker and makes decisions are made on time. This helps to have a continuous focus on the value forecast with respect to the business case and manage the risks that may potentially impact on the expected value.

Principles of Governance

The following are the key governance principles for a successful governance of Agile Delivery:

Focus on the value delivery - only do a task if it brings value to the business. This principle also recognizes the timely delivery of a task as the value derived is more likely to deteriorate with the delayed delivery. In case of Agile deliveries, the governance is continuous and at a work unit level. It should also focus on what activity is taking place and the value such task delivers.

Embrace Change - This another principle of Agile and the Governance framework should take this into consideration. This would mean that the decisions or work flows should be flexible enough to change course based on the feedback received. Given that all stakeholders collaborate, decisions should be taken across the table, without putting things on hold and for the purpose, all needed specialists should take part in the reviews.

Decide on the performance metrics - Another key principle of Agile methodology is to 'fail fast and learn quiuckly'. Given that the overall objective is to improve the certainty that the team will deliver a usable product or service of good quality, the teams should be able to identify and implement the right metrics that will accurately indicate the quality of the deliverables and the performance of the team. For example they measure tasks completed; rework they had to perform; the backlog list and the value of the product or service to the business at the end of each iteration. Teams display this information visually, updating it frequently. This makes progress transparent to business users and management. If senior managers require performance information to oversee projects, they define what the ‘must have’ data are. Performance reports for senior management become a task in each iteration and an output of the delivery team.

Collaboration - All stakeholders, including senior management, external assessors, business users and the development team should be partners in quality, and this collaborative approach is an essential change in mindset. The business owner and delivery team defines what ‘quality’ tests they will use and what results are acceptable at the outset of each iteration – the definition of ‘done’. Regular user feedback identifies whether the product or service is providing the expected business value at each stage. External assessors are not gatekeepers; rather they are an integral part of the team. The iterative approach ensures continual reviews and feedback on progress, so external assessors are not just involved at critical points as defined in a traditional project life cycle.

Focus on behaviours and not just processes and documentation - More specifically, the external reviews or assessments will be more effective in providing critical challenge if the assessors have high-end skills, including technical and Agile delivery experience. In addition, they provide better value if they continually review how the team is performing, using observation as their main method of evidence collection. The focus of such external review or assessment shall be on the following:
  • the skills and experience of the team;
  • the team dynamics – frequency and nature of communication inside and outside of the delivery team, and the level of input to the delivery team from the business;
  • the organisational culture – the level of commitment and openness;
  • the timing and nature of quality control by the delivery team – the testing and release framework;
  • the order in which the team tackled the tasks – prioritisation of actions and deliverables, the amount of actions in the backlog list;
  • the way the team changes its activity in response to the results achieved in each iteration; and
  • the value of outputs to the business.

IBM's Disciplined Agile Delivery Methodology

IBM believes Agile delivery allows it to continually issue new capabilities that meet user needs. It usually introduces software as part of a wider business change project so, to keep both in step, it has developed several Agile project methodologies. Disciplined Agile Delivery is a hybrid method that can be applied by a large number of teams working on the same project at the same time. The image below shows the Disciplined Agile Delivery life cycle. It starts with a few short iterations that allow the team and its stakeholders to identify the initial requirements, develop the architecture and agree a release plan. IBM also uses this to determine the system level properties and characteristics – the non-functional requirements. There are iterations after the business owner has decided that the system has sufficient functionality. These additional iterations are necessary for IBM to support the operation and maintenance of the solution once it is in service.

In contrast to the traditional approach of looking at outputs, plans, resourcing and how a project is organised, external assessors should focus on outcomes, prioritisation of work and team dynamics. The most useful indicators of success are how the teams are organising the delivery of an operational service or capability and what Agile behaviours and practices are used. Areas for assessment include whether:
system level issues (security, availability) are addressed within the iterations;
  • short- and longer-term planning exists;
  • the stakeholders have a shared vision;
  • there is continuous integration; and
  • the team has the right people


National Audit Office's Review on Governance of Agile Delivery

Sunday, June 22, 2014

Sustaining Successful IT Governance Environment

A tremendous amount of importance is being given to governance, risk, and compliance (GRC), ans thus IT governance is becoming a necessity in today's business context. There is strong pressure on senior management and the Board members to have a good understanding of their IT systems and the controls that are in place to avoid things such as fraud and security breaches. As the global corporate and economic climate continues to shift, businesses need to be prepared to anticipate, respond to, and mitigate risk with flexible processes that can be adapted to any methodology. This calls for assessing and continuously monitoring of the IT Governance as it operates in an organization.

IT governance represents a continuous journey (not an end state in itself), which focuses on sustaining value and confidence across the business functions. Many companies start on a short term approach and focus on the compliance component of IT governance, without developing a balanced longer term approach consisting of both a top down framework and roadmap together with bottom up implementation to address the broad range of IT governance issues and opportunities in a planned, coordinated, prioritized and cost effective manner. 

Getting it Right First

Different IT governance stake holders need different features so the solution needs to be structured, taylored and feature risk management. Because process is at the heart of IT Governance the solutions has to be process centric but also support all other perspectives, organisations, technology, application, infrastructure, etc. Being process centric, IT Governance aspects should be integrated into the existing process framework of an organization, so that it becomes real, operational and sustainable.

It is important to get the IT Governance pieces well integrated and have the same operational first. To have an effective and operational IT Governance program, at the minimum, the following should be taken care of.

  • Executive Commitment - The Board and the Executive Leadership Team are committed to implementing and sustaining a robust Governance environment.
  • Do Homework - Educate yourself on past, current and emerging best practices.
  • Gather knowledge - Develop, adopt, integrate, leverage and tailor current and emerging best practices models, frameworks and standards to make them work for the enterprise - create an integrated IT governance framework and roadmap for your organization.
  • Sell it - Market the IT governance value propositions to the organization and communicate its goals and objectives.
  • Assess Current State - Assess the “current state” of the level of IT governance maturity and identify gaps. 
  • Define Future State - Based on the knowledge gathered, develop a “future state” IT governance blueprint.
  • Implementation plan - Come up with an implementation plan by breaking down the components into well defined work packages and assign an ownership and responsibility.
  • Roll out - Implement a scalable and flexible governance policy and process.

Continuous Improvement

There could not be a second thought in that the IT Governance needs to be sustainable by putting in place a lifecycle for continuous improvement.  IT Governance like any other process framework need continuous improvement in line with the changing business and technology environment and to ensure that the desired benefits are realized for ever. While the improvement cycle can be as simple as that of Demings PDCA, ISACA has suggested a seven step cycle as below:

  • What are the Drivers?
  • Where are we now?
  • Where do we want to be?
  • What needs to be done?
  • How do we get there?
  • Did we get there?
  • How do we keep the momentum going?

At the minimum, organizations should address the following questions to have the IT Governance continuously improved and thus sustained:

Image Source: The Advisory Council

With an integrated IT Governance framework in place, these improvement steps cannot be performed in isolation for the IT Governance function alone. Such improvement life cycle shall be applied to each of the functions, like Service Management, Asset Management, People & Project Management, and IT Portfolio Investment Management. The improvement life cycle shall thus at such levels and when such functions improve and deliver the desired results and value, IT Governance in turn will also be delivering. 

How much is enough?

As a process, operational governance must be carried out by one or more people. Even though it is useful to treat governance as outside the day-to-day operations of an organization, those carrying out the governance process may or may not belong to the governed organization. Even so, those who are carrying out the governance process must be concerned with certain external forces on the organizations as well. These external forces could be External Policies, External Standards, Government Regulations, etc. 

It is needless to mention that continuous improvement of IT Governance requires investment and it is equally important to justify the investment in continuous improvement pays back. Thus, the organization should know how much improvement is enough for them and accordingly focus its resources for this activity. However, knowing how much of IT Governance is enough is a key challenge, which will depend on the following factors:

  • Investment in IT (capital and expense), strategic value
  • Management philosophy and policy (e.g. mandatory and discretionary)
  • Program/Project and/or Operational visibility
  • Complexity, scope, size and duration of initiatives
  • Number of interfaces an integration requirements
  • Degree of risk
  • Speed of required implementation
  • Number of organizations, departments, locations and resources involved
  • Customer or sponsor requirements
  • Type and location of outsourcing (e.g. domestic, international)
  • Regulatory compliance 
  • Level of security required
  • Degree of accountability desired and audit-ability required (per external auditors)
  • Management Control Policies and Guidelines

Key Principles

To sustain and continue to make progress on the journey to achieving higher levels of IT maturity, an organization should adopt select principles from managing and accelerating change and transformation, which include the following key elements:

  • Proactively Design and Manage the IT Governance Program. Requires executive management sponsorship, an executive champion and creating a shared vision that is pragmatic, achievable, marketable, beneficial and measurable. Link goals, objectives and strategies to the vision and performance metrics and evaluations.
  • Mobilize Commitment and Provide the Right Incentives. There is a strong commitment to the change from key senior managers, professionals and other relevant constituents. They are committed to make it happen, make it work and invest their attention and energy for the benefit of the enterprise as a whole. Create a multi-disciplinary empowered Tiger Team representing all key constituents to collaborate, develop, market and coordinate execution in their respective areas of influence and responsibility. 
  • Make Tradeoffs and Choices and Clarify Escalation and Exception Decisions. IT governance is complex, continuous and requires tradeoffs and choices, which impact resources, costs, priorities, level of detail required, who approves choices, to whom are issues escalated, etc. At the end of the day, a key question that must be answered is, “When is enough, enough?” 
  • Making Change Last, Assign Ownership and Accountability. Change is reinforced, supported, rewarded, communicated ( through the Web and Intranet), recognized and championed by owners who are accountable to facilitate the change so that it endures and flourishes throughout the organization.
  • Monitoring Progress, Consistent Processes, Technology and Learning. Develop/ adapt common policies, practices, processes and technologies which are repeatable across the IT Governance landscape and enable (not hinder) progress, learning and best practice benchmarking. Make IT governance an objective in the periodic performance evaluation system of key employees and reward significant and sustainable progress and achievements. 

People often think they have a choice between "governance" and "no governance," but in reality the choice is between "good governance" and "bad governance." Every organization has a framework of decision-making and some set of often unstated measures. The needs of the business and the role of IT evolve; these unintentional governance solutions do not. Good governance is intentional, and it takes effort and attention. The operational perspective described in this article provides an approach for doing governance well.