A presentation given at Arrow ECS Inspiration Day 7th of March 2014, Tallinn. The deck elaborates on why it is important to have information security built into your systems rather than tacked on later and offers some approaches to actually doing it.

1. Information security in practice
Why do you really need it
Andres Kütt
Information System Authority / Information System Architect
!
07. March 2014

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

3. 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?

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

5. On system boundaries
In case of information system security,
determining the boundaries of the system in
question is of paramount importance
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.

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

7. Concept is developed
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
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.

8. System is designed
The functions are mapped to elements of the
system using the concept within the boundaries
of the known constraints
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.

9. The described process has a major
impact on information security
It is almost impossible to retro-fit security to a
system that is already designed and/or
implemented
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.

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

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

12. Security domains across layers
Security
domain A
Security
domain B
Security
domain C
Functionality
Implementation
Infrastructure
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.

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

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

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

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

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

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

19. Thank you!
Andres Kütt
andres.kutt@ria.ee