What Enterprise Architects Need to Know About…Security

An Interview with Pascal de Koning

By The Association of Enterprise Architects

With the increasing speed at which new technologies are being introduced and the convergence of trends such as Big Data, Mobile, the Internet of Things, etc. emerging to become what industry pundits have called a third platform, Enterprise Architects (EA) have more to consider when building and maintaining architectures than ever before.

With this blog, we are introducing a new series called "What Enterprise Architects Need to Know About…” that will look at industry trends and issues that EAs need to consider as they put together architectures and do their day-to-day work.

In the first of this series, we talked to Pascal de Koning, Senior Security Consultant, Ideas to Interconnect, and the Co-Chair of The Open Group’s next version of TOGAF® Security Project about the things EAs need to consider when it comes to including security in their architectures.

What are some of the basic things that every EA should be aware of when it comes to security?

To start, I think they should engage with the Security process. They should find someone who is responsible for Security within the enterprise and make sure they are part of the team or part of the plan.

What you see often is that Security is an afterthought. Things are being designed and developed and afterwards, just before going live with the environment, the Security guy has to give a green light for it. That’s far too late, and that can be easily avoided if there’s a conversation early in the process.

I see Security as an enabler of doing things. For example, if you want to do e-commerce, you can only do that if the transaction is trusted. You need to provide confidentiality when exchanging data, you need to assess the identity of the person on the other side, you need to establish trust before you can do any transaction, so it’s in fact the enabler.

Are there other things that EAs should consider when it comes to security?

Security should also be taken into account when doing requirements management, which is a central process in TOGAF® 9. Within TOGAF, an Open Group standard, it’s more about functional requirements than Security requirements. Security’s just another type of requirement that you need to take into account.

The most important thing is to have security integrated in requirements management because that will influence all phases of the build process and implementation, as well.

What are some of the latest trends in security that EAs need to be aware of these days?
What we are doing now is tying everything together and exchanging information between enterprises. Who’s the owner of the information? What am I allowed to do with it? I can do things with it you’d never have imagined, especially if you look at Big Data analysis or analyzing social media information. Am I allowed to do that? There are more questions about what you may do. It’s becoming more complex.

What you also see is that the security field—the hacker field—cybercriminals are very professional and they are professionalizing day by day. I truly believe that most people are underestimating that and are sometimes quite naïve in putting things out there. The level of sophistication of the cybercriminal industry is very high, especially compared to the regular ICT (information and communications technology) development industry. I think the best developers are on the side of cybercriminals. We are just ignoring that in a way.

To give an example of security risk ignored, at a certain company we have done a phishing test and we saw that 20 percent of the employees give their passwords once they are approached by a phishing attack. We also know that many of their information systems are protected only by user names and passwords. Recently, the company has been hit by a real phishing attack and lots of passwords have been captured, but that’s largely ignored by the organization itself. This is a problem. But as long as no one publicly steals information and claims he has done that, it goes unnoticed. It’s hard to prove or monitor what’s going on. But if you just take the facts and add them up, then you can conclude what is happening even without proof.

How much does someone need to know about security to create a Security Architecture?

To do the latter, you need to be a Security-educated professional. If you are an Enterprise Architect, you need to know that you need that type of guy to join your team. That might be a Security Architect but, like I said, it’s also very good if you get someone from the Security management group, someone that’s able to advise you thoroughly in the architecture development about what to do about security that’s also able to schedule the tests and assessments at proper times during the development phase.

If you’re not educated in Security it would be hard to oversee it all, but you just need to know that you need someone to do it—that’s most important.

We are now integrating security into TOGAF. We’re defining the core Security elements that should in fact be part of the whole Enterprise Architecture. The idea behind that is, once they are part of the core framework then it will be normal and people will be more likely to use it. It’s not rocket science; just adding security requirements to the functional requirements is an easy thing, but it has not been done yet in TOGAF. These are very basic things that we’re adding. And it goes both ways—there are a lot of things that Security Architects should use that have been developed by Enterprise Architects. For example, the description of business processes as starting point. That has a lot of value for the Security Architect. There should be an exchange of information between the two. We are trying to facilitate that by creating a common glossary of terminology so that people can talk to each other and make clear what they need and what they can deliver themselves.

Another example—if you look at information systems, within TOGAF there’s no information system classification. But within the Security field, it’s very common to classify information systems for confidentiality aspects or availability aspects. Then based on that classification you will find the requirements that may apply or you may find the Security services that you need to implement in your environment. For example, an authentication service that delivers strong authentication or trusted employee requirements—this classification guides you to the proper measures—where to find them and whether you need to implement them. But the attribute of classification is not yet in TOGAF, so where do you fit it in? That’s the sort of things we’re aiming for—to create a placeholder for security to become a common part of the TOGAF artifacts.

How can EAs build security into their existing architectures if it’s not already there?

It’s just the same as when you create an enterprise Security Architecture—you start by defining what problems you would solve. That dictates the components you are going to develop. In an existing Enterprise Architecture, that might require the extension of some models that you use, or the introduction of some new models for security.

At current we are developing a Security Services Catalogue, which is in fact a unified description of over 200 security measures that you can take. It defines Security in the TOGAF vocabulary—with building blocks—that way it will make more sense to Enterprise Architects. This will also help enormously to position Security as an enabler instead of an inhibitor. A lot of Architects are looking for ways to incorporate Security in their architecture, and the idea of the catalog is that you provide a central list of security services that offer the proper protection for specific situations.

We currently have 60 people working on this global project. People from New Zealand, Canada, the US, South Africa—from all over the world. It’s an exciting project that is gaining traction. It’s a joint effort between The Open Group and the SABSA Institute to develop this catalogue. We will write the guide for both TOGAF practitioners and SABSA practitioners to use that catalogue. By providing this practitioner’s guide for TOGAF users, we’ll make it easier to implement security in the enterprise architecture. 

Is it best to hire and have dedicated Security Architects on staff? What should small companies consider if they don’t have the resources for Security Architects?

They have the same issues to solve, namely to address security properly. The project might be smaller because the environment is smaller. If you look at the process of delivering a Security Architecture—standalone or preferably as part of the Enterprise Architecture—you go through phases like defining what you need, designing what you need, then comes the implementation and after that you start to measure it if everything goes according to plan. You’ll still go through all the phases, only quicker.

What size does a firm need to be to consider having dedicated Security Architects?

Maybe the same size that has dedicated Enterprise Architects! It’s really a maturity thing. If they don’t use any architecture, you might start developing a Security Architecture but I doubt if it will last very long. You might lack the maturity to maintain it. I have worked for organizations that are very skilled in the security area but they still did not have the maturity to maintain a Security Architecture.

What I see a lot of times, too, is that the Security Architecture is set up once to define the security strategy and subsequently implement the proper measures afterwards it’s just thrown away because no one is there to maintain it. That’s not a problem, it’s the way it works and the Security Architecture was meant to deliver just that. It also means you don’t have to set up a whole process for maintaining it.

Are there certain types of organizations or industries that absolutely should have a Security Architecture?

If you look at Financial Services, they are very sophisticated in the way they address Security. You also see the demand there for Security Architecture. There’s also room for it in the central government organizations. People there seem to value these kind of things more—they see more value in doing things the right way, taking the time to do it right. Where I would also expect it is in complex environments, such as the Healthcare industry, where you’ve got a lot of sensitive information that you are exchanging in real-time with many different parties. I would say that definitely needs a Security Architecture to be able to do that properly.

What are some things that hiring managers should look for in Security Architects?

For enterprise Security Architecture, the best thing to look at is SABSA certification. SABSA has a business-driven approach toward security and it fits very nicely with TOGAF because it has the same perspective, a business-driven perspective. SABSA provides a set of training courses and a certification.

For the rest it’s more or less the same skills that you would expect from an Enterprise Architect—the ability to communicate. Communication is always the toughest thing.

Are there other things that you think EAs should know about security or Security Architectures that you haven’t mentioned?

They should just stop calling it "Security Architecture” and instead make Security part of their Enterprise Architecture. That would help.

What can people expect from the security measures being built into the next version of TOGAF?

The Security Architecture strongly relates to Enterprise Risk Management and Information Security Management. These two processes are leading in the way we integrate Security and Risk in the next version of TOGAF. At this moment we are finalizing the Foundation document. It describes the core Security and Risk elements that should be part of TOGAF. I expect that this will be ready in February. After that, we will write a practitioner’s guide based on this foundation document so that people are actually able to use it. Eventually, security will be dealt with in TOGAF as a cross-cutting concern.