Security Think Tank: Dialogue between data architects and security leads is essential

There is a tendency to identify different groups of technologists – data architects, network architects, security architects – and for them to work in isolation, particularly at the start of a new project, or system development.

There are natural tensions between these groups – particularly the security professionals who will have different priorities to others, focusing on data protection and privacy rather than on performance and data exploitation.

As a result, there can be a tendency for security to be seen as a blocker. I have seen systems designed with security professionals included only at the last minute to approve the security system they’ve had no hand in defining, and then be blamed for delaying the project.

It’s therefore critical that security professionals are included from the outset and all parties understand and accept the others’ objectives to achieve the best overall solution.

Data architects are probably most closely aligned to the business purpose, potentially responsible for defining a common business vocabulary, identifying strategic data requirements, preparing high-level architectures to meet those requirements and ensuring alignment with business strategy.

Early dialogue between the data architect and security lead is essential, so the security team can understand the proposed approach and business context, plus potential security constraints can be identified to the data architects. From this point on, it will be necessary to take the perfect functional design through a number of iterations to a point where data architecture fully supports the business strategy while the security risk is acceptable.

The best approach to make this happen is to start any new project by forming a multi-functional team at the start, before any technical requirements or architectures have been identified. This is generally not enough in itself because team members need to see the value of input from others by seeing changes not as compromises, but as adding value to the overall solution in line with the business aims.

From a security point of view, one of the first activities will be a risk assessment. While this is a security risk assessment, it needs to take into account the business objectives, as it is the risk to the business that ultimately counts.

You can secure a system to the hilt, but that approach may effectively be a denial of service against the business objective. Also, if the security makes life difficult for the users, they will find ways of getting around it to get their job done, which may undermine the security of the system. Availability and usability should therefore be common goals of security architects and data architects.

Ultimately, getting teams to work together is a matter of culture and trust. Where a culture of cooperation, trust and respect does not exist, as with any culture change, it will take leadership from senior managers to make it happen – and even where it does, it needs visible support to reenforce the approach.

Most organisations will have business and design reviews at key points in the development and operational lifecycles of their systems, which should address security as well as functional and operational issues.

This will ensure security is addressed early and highlight any security issues. They will also reveal any issues in the ways of working, but are not sufficient to guarantee collaborative working. This will come about only through the establishment of common goals, understanding of the other’s motivations and respect for their contributions, supported by leadership from senior management.