Information security in practice Why do you really need it

Andres Kütt Information System Authority / Information System Architect !07. March 2014

Agenda today

" Information security from the architects perspective

" Implications of security on system design " Approaching information security in a

standardised fashion

It must be emphasised, this is not a security centric view. The speech will not go into specific security details but will rather cover designing systems with security considerations in mind.

So what does an architect do anyway?

" He or she designs systems " What are systems? " What does it mean to “design” something

To understand what system architecture is and why it is vital, it is important to understand, what does an architect do. !So an architect designs systems. What do the two elements of that definition actually mean?

What are systems?

" In an abstract sense, collections of things relating to each other " The things might be software, hardware,

people, activities etc. " So where exactly does my system end?

Systems are collections of things (including other systems) relating to each other in a way. It sounds abstract but is a rather important realization as this means people, hardware, processes and software form equally important elements of any system. !Since this definition is rather abstract, it raises a question about what things are included in the system. Since everything is realted to everything else, don’t we have the entire universe as a single system? While this is, stricktly speaking, true, it is impractical to design the entire universe every time we want to build a website. Thus, there must be an explicit decision about what is included in this particular system and what is not.

In case of information system security, determining the boundaries of the system in question is of paramount importance

On system boundaries

Information security is about protecting the information in the system against unauthorized use. Therefore, it is absolutely paramount, that all elements of the system are considered when thinking of how to protect the information. !Typically, for example, people are left out of the system, they are considered just “users”. However, how many of you will happily connect to any open wifi hotspot during this event as long as it is called “somethingsomething FREE Swissotel”? Unfortunately experience shows, the answer is “many” and that people are often the weakest security element of all the systems. The same is true for processes. It is rather pointless to encrypt a database when there is no process in place to ensure the application software does not write a debug log with all database input and outputs in the production environment.

Inputs to the design process

" Functionality or value to deliver " Known constraints:

" NFR " Execution constraints (competences, time,

money) " Information security requirements " Operational constraints

The first, but not the only, input to the system design process is the functionality to be delivered. Regardless of whether the customer can express this, there is a structure to the functional requirements that can be referred to as “functional architecture”. The better and more explicit that structure is, the easier the work of the architect is. Level of detail is not necessarily a good indicator but the structure is. !The second class of input are the NFR (essentially an agreement between technical parties about what constitutes a “good” system), execution constraints (i.e. whom do we have available to build the system using what tools, how long to we have to do this and what are the manufacturing tolerances to be expected) and information security requirements. !It is important to realize that this is usually where the boundary between the customer and service provider lies (again we are dealing with system boundaries). Unless there are explicit security requirements, they will not be taken into consideration and the system will be insecure. It is not enough to state that “the system must be secure”. It is the responsibility of the customer to procure a secure system exactly as it is the responsibility of the customer to procure a system that performs the necessary business function.

Based on this input, a concept of the system is developed, that embodies basic metaphores, thought patterns and values that form the foundation of the design

Concept is developed

An architect takes the input described previously and develops some sort of a mental model of the system to be built. This is not necessarily a conscious or explicit process but every architect does this nevertheless. Basically, a concept is about how people think about the system.

The functions are mapped to elements of the system using the concept within the boundaries of the known constraints

System is designed

At this point the architect takes the functional elements and map them to technical components based on the concept and within the boundaries of known constraints. How exactly this happens, is part of the art of an architect but at this point already it is becoming late to start talking about security.

It is almost impossible to retro-fit security to a system that is already designed and/or implemented

The described process has a major impact on information security

If one looks at the steps that have been taken in system design up to this point, it becomes clear that retro-fitting security to a system that is already built is neigh to impossible. In the following, lets review in more detail, why this is.

Fundamentally, it is about the concept

" All design decisions, big and small are based on the concept

" Unless the concept already contains the notion of security, the decisions down the line will not consider it

" It is also impossible to tell, which ones do and which ones do not

If the concept forms the basic mental model about the system and that model does not involve security, the system will not be secure. The main reason for this is that, either consciously or subconsciously, all design decisions made during the design and build process of the system, are based on that basic mental model. And unless the foundation includes some premise of security, there is no way to tell, if any of the subsequent decisions are taking security into account or not. Even worse, it is impossible to tell, where security is thought of and where it is simply forgotten or bypassed as a project-induced shortcut.

Level of detail in the design

" Rule of thumb: the more secure the system, the more detailed the design

" The less freedom the developer has " Or, we could choose to trust the developer

As a rule of thumb, a more secure system requires a more detailed and thoughtful design process. Whether that process is undertaken explicitly or is offloaded to the heads of good developers, matters little. The point is that both the choice of the level of detail in system design and the selection of developers can only be made once. Re-iterating these decisions basically means re-engineering the entire system and building it from scratch.

Security domains across layers

Functionality

Implementation

Infrastructure

Security domain A

Security domain B

Security domain C

Security domain is defined as a system area with similar security requirements. The boundaries of the security domains of the system must be clearly defined and protected through functionality, implementation and infrastructure layers. As the uncertainty about the details of the system decreases while the system is built, it becomes more and more difficult to draw boundaries between the security domains and thus, it is very hard to retro-fit security domains to an already built system.

Security domains

" If the system contains multiple security domains, they should be aligned

" There should be clear boundaries with access control and logging between the domains

" External boundaries of the system are also security domain boundaries!

To have the security domains aligned across layers means, that the boundaries of components on the layers must not cross the boundaries of the security domain. If there is one functional piece (i.e. data warehouse, self-service etc), it must not belong to two separate security domains. If there are two functional pieces belonging to separate security domains (internal application administrator interface and external end-user interface, for example) they must not be deployed into the same virtual box. !Clear boundaries with access control and security monitoring must be in place between the domains. By the way, the external boundary of the system is also a security domain boundary and thus needs to be considered carefully. Usually, only user interfaces are considered but technical interfaces need as careful consideration. It is perfectly possible to have an SQL injection attack vector through a machine-machine interface that is nicely encrypted and authenticated.

Holistic security of the whole system

" It makes no sense to protect one part and neglect others

" What were our system boundaries again? " It is very easy to over-react " It is also easy to under-react and forget things

It is important to have the same level of security across a security domain. It makes no sense to invest into protecting one part of the system while neglecting others. Again, the question of system boundaries appears as often things on the vague edges of the systems are where security breaks down. For example, is a data warehouse part of your system? If you choose to encrypt your database but do not protect the results of functions that, by definition, are meant to increase the value of the information, there is a problem. !It is easy to err on both sides by either over-spending on security or under-spending. You do not want to build a cast iron gate to a simple wooden garden fence, neither do you want to have a latch-and-hook in a stone wall.

Information security has to be built into the entire system up front, retro-fitting is expensive and likely to leave gaps

Holistic security built in

Approaching security: baseline

" Use a baseline security standard to validate the measures in place

" Cheap to impelement, easy to under/overshoot " In Estonia, ISKE is obligatory for the public

sector, OWASP ASVS becoming more prominent " This does not relieve anybody of the burden of

thinking!

The idea of baseline security is to take a hypothetical, standardized, system and perform a risk analysis on it under typical conditions. The results should then, to an extent, be applicable to all similar systems under similar conditions. While it is relatively cheap to implement, it is easy to over/under shoot as it is not necessarily clear how your system or risks deviate from the standard. Therefore, baseline security is exactly what the name says: a good baseline. Nothing more and nothing less. There is still a need to think about what you are doing in terms of security.

Approaching security: risk analysis

" Conduct a tailored risk analysis of the systems at hand and the processes surrounding them

" How often are you really willing to do this? " How to respond to both of risks and the

systems changing continuously?

As an alternative, one can choose to perform a thorough risk analysis of the systems including processes around software. While, when done properly, this produces very good results, the choice between the approaches is not trivial as it is not about a one-time effort. Security needs to be holistic over space and time, thus one needs to be ready and willing to spend resources of repeating the analysis frequently.

Summary

" Security has to be built in. There is no other way " Think before spending money " Think after spending money " Pick a sustainable approach to security and

stick to it

Thank you!

Andres Kütt andres.kutt@ria.ee