How to create an Information Security Architecture Program

In a previous article in the blog I described the need for the information security architecture program. It begs the question: how do you build one?

As it is often the first point of entry into the information/cybersecurity world, the information security program needs to be easy to use and and streamlined. There are several paths to follow: TOGAF (https://www.opengroup.org/togaf), SABSA (https://www.sabsa.org), COBIT, and may articles by such experts as Grady Booch (https://softwarearchitecturezen.blog/tag/grady-booch/ ). They are all necessary reading and need to be part of a Security Architect's training.

However, in my experience, for a financial institution, one needs to be practical. A simplified version of these programs is much easier to work with and easier to explain to the wide constituency in IT and the business that a Security Architect has to deal with. So keep it simple.

Its best to start with the realization that Information Security Policy imposes a set of policies and subsidiary control standards in order to contain and manage cybersecurity risk. Those policies and standards mandate a series of controls on IT and a wider corporate environment that need to be enforced. As security architect these need to be designed into the builds of applications, infrastructure, and business processes. This is what is generally meant by "architecture": as the "security zoning board" of the company, you need insure that things are built according to those controls and things that are not are either modified to fit the controls, or if a new need arises, the controls need to be adapted by modifying, adding or changing the implementation of them to meet the new circumstances.

To do this, your first stop as security architect is to built a set of reference architectures that show how to implement those controls and map them back to the Security Policy and the general architecture of the firm. The reference architectures, in your role as zoning board, are a set of plans on how to build an application, a piece of infrastructure or a process in your firm. On top of those are layered the Security architectures. You also need to be a proponent of the best and most practical technology for the job, not the perfect one. Although there are a lot of good ways to build things, every firm, like a city, must settle on a "way to build things here". The other side of this that you need to work on building into your security policy (its an iterative/Agile process) the controls you will implement.

For a security architect, this leads you in a simplified model, to a functional architecture: what functions are implemented in your environment to implement your controls. These generally fall into several very well known swaths: authorization controls and the tools to implement them (passwords, tokens, biometrics, more advanced stuff), access controls (who determines who accesses what info and how), encryption controls (to protect data), identity management, logging and event management, threat and vulnerability mitigation, and education. These are the most important, but you can get very detailed as the program becomes more mature.

As you build your reference architectures to apply those controls, you will need to decide on what controls to implement (when is 2 factor authentication needed) and the what technologies you are brining in, what are approved, and what are going to be sunseted (e.g.) are biometrics in your future, are they to be implemented now, or are they too much?). This is your Technology Architecture. Think of it as a grid where you have the functional architecture needs aligned down one side, and across the top the different situations you are building for: e.g. internal lan, internal wan, internet, mainframe if you have it, and the cloud. In each of those boxes then goes a tool that is approved. Behind that needs to be a robust technology evaluation and piloting program that you are running to look at new technologies and bring them on board or not. A word of caution here: there are many "neat" and good technologies out there. However, your job as architect is to find the right technology for your firm at a cost level your firm can afford (see my last post: build with brick in London, not costly stone that needs to be imported).

Now comes the personal part of your job: you need to setup processes and relationships within the firm, within IT and with the business, so that you are the person to go to for new projects, projects being built, and remediation projects. You need to have a seat at the table to influence directions. You can setup a process whereby all new projects need to declare the type of data they are dealing with and if they can fit into your reference architectures. That will give you an early warning of things that don't "fit". You are not a dictator, so your ability to stop bad designs will depend heavily on your powers of persuasion and your ability to suggest alternate/more secure designs sometimes incorporating new technologies that you will have to understand in a hurry. Reading about new technologies and being able to judge them is a must.

Your next step is to work very closely with the other parts of the information security, the engineering, and project disciplines to make sure that those things agreed to in the design stage come to fruition in the build and deploy stage of the software (here you work with Application Security), the infrastructure (here you work with Security Operations), and processes (here you work with the business and project management).

There is a lot more in practice to consider, but that is what a security architect should be doing tactically and strategically. Its a large body of work to cover and there is often a steep learning curve on technologies and processes that you are not expert in. However, if you are a quick study, you can have a deep effect on the security of your environment.