Applying Information Classification To Systems

I wanted to share a simple way I learned of practically applying information classification to IT systems.

I’ve spoken already about Information Security Thinking – this blog is more about ways to practically apply information security to networks and devices. This isn’t the scheme I use in my current job, but one I periodically find myself talking about.

Classifying information

Normally there are variations on a theme for information classification that may go something along the lines of this:

  • Public – Anyone can see, no real restrictions
  • Internal – Limited to people within the company
  • Confidential – Information has a controlled audience of stated members
  • Secret – is the information that could cause significant harm.

This can of course be customized, but as a rule of thumb most people agree we want to keep the information classification structure as simple as we can.

Establishing Controls & Control Goals

Each Information classification is expressed as a control goal – I made up a random example below; its not complete, I modeled this just as an example and to show how we can model this..

Figure 1 – Control Goals

The reason I show the influence relations between the classifications is because we effectively ranked information classification, and layer controls on top of each other. What I mean is if we had confidential information (Layer 3) it was expected that you would apply the confidential controls, but also the internal controls (Layer 2), and the public ones (Layer 1). Secret classified information would effectively necessitate the application of all the controls from the lower levels.

In this way its fairly easy to see how much control we need to apply depending on information classifications.

Applying Information Classification

Effectively once doing this you can designate an information classification to a network, or to a device on the network. Like this:

Figure 2 – Assigning Control Goals

In the example above I simply showed control goals associated with networks. In Figure 2, Effectively I have created Public, Internal and Secret security domains. In the real world I may map the different networks against the different security domains, as in larger organizations there are normally many networks. I simplified for demo purposes.

All devices and networks have an information classification. The rule is, that you are only allowed to have information up to the level of its information classification in any given system. For example a web page from public would be allowed to reside on either internal or secret systems, and its normal to put mechanisms in place to ensure that information coming into systems does carry an information classification, and also that the information classification is allowed on that system or network.

If a lower security classified server is on a higher security network it must adhere to the rules of the higher classification. For example, a web server might have been classified Public – meaning anyone can have access to the information. If we put a web server on a secret network, that’s OK – but it needs to adhere to the rules of the secret network – which in our example might mean that this public web server may not be allowed to have access to the internet.

What happens when the rules are violated?

If for example someone was to put secret information on an internal classified network, a couple of actions may be taken, for example.

  1. That information can be removed, and in depending of the seriousness of the infraction disciplinary action may be taken.
  2. Because a network has to provide a level of protection for the highest level of classified information on it, you could reclassify the network & the servers on it and apply the necessary security controls.

The actual rules should be considered carefully and included as part of a security policy.

Some Security principles

Following the discussion above these are some basic security principles:

  • All networks and devices are designated an information classification.
  • The information classification of a device may not be greater than that of the networks it is connected to.
  • All networks and devices must implement the security controls related to their corresponding information security classification.
  • All devices on a network must also implement the controls of the network they are on.

So whats good about this?

There are a few reasons I like this way of doing things.

  1. It makes the connect between the information we store and the controls we need to secure it.
  2. It can be easily represented in a few architecture views, and is a simple scheme that’s easy to understand, teach and communicate. Less is more.
  3. Because you are applying controls at a network and device level its very easy to see at a quick glance where security is, and gives simple clear rules that help us protect information
  4. It enables IT people to be focused on the protection of information rather than the protection of technology.

Summing it up

When trying to apply security to large organizations the security landscape can get really complicated fast. Its not uncommon to have comprehensive security rules that have grown in complexity and are not followed. This isn’t always because people do not want to follow security rules, its more often because there are already many demands on people & they do not always understand the value of applying security and don’t prioritize it

In designing any kind of security its important to get a balance between ease of use, and effectiveness, because if security policies and rules are too restrictive people will look for and find workarounds.

Control Services in ArchiMate

Control Services are a mechanism we can use to implement security control measures. I wrote this blog to demonstrate that controls are real things, which we should carefully consider; not just line items on a spreadsheet.

The Common Understanding Of Controls

I’ve seen very varied levels of understanding on control measures.

The most crude level of control implementation I have seen is where a project just runs through an excel with a list of questions. For example, they will simply ask the question “is the web server traffic authenticated?” and a technical person says “yes”.

That’s not really a control so much as it is a check of the current state. Some people argue that the exercise of running through the checklist and answering those questions is a control – and to a limited extent I can except that; This basic checking is better than no checking. However, There are varying levels of control, I tend to think about controls in terms of continuous control.

Its important to note there is a balance to be had; In designing any solution you need to think about your requirements, and you need to think about effort, vs return. Its just as easy to over engineer things as it is to under engineer them. Every now and then when I am designing something I stand back and ask myself – is this too much?

The subject of fully modelling security will take a few blogs, and wont try to cover everything here. A lot can be said around FAIR / SABSA way of doing things. There’s a whole bunch of related concepts and elements that I am not covering here.

The Control Measure

Figure 1 – Realizing a control

There are many frameworks out there that have security controls – for example the Cloud Security Alliance has the Cloud Controls Matrix. When representing a control it can be modeled in standard ArchiMate as a Goal element. Those of us using BiZZdesign’s Enterprise Studio (BES) have a set of elements especially for risk management – so we can represent them directly. In our example we are going to use a fairly simple control – Authentication – a standard control that exists in any number of frameworks. Figure 1 – shows how a control service realizes a control. In BES security controls can be modeled in figure 1.

For those using BES, Control Services can be created in a risk and security view. Although that view type only has a few elements in the create window, its possible to paste architecture from other views into a risk and security view. Enterprise studio will also allow you to assign a control strength to a control and has a number of features relating to modelling risk and security. Control services in BES – have a padlock next to them.

Showing a control service within your architecture

Representing a control service as part of an architecture model is easy. so as an example if I created my Authentication Control Service you could see it represented on a diagram like this:

Figure 2 – Implementing a control service

In this case I have associated my service with some application components. Already this beats the approach of just saying “yes, we have authentication”. Its showing how our controls are implemented; we can see exactly where in our architecture our control is enforced.

Designing a Control Service

The authentication control is a simple example, but right from the beginning I can ask some simple questions:

  • How do I ensure that control is being continually achieved?
  • What do I want to happen if things fail?
  • How much of this control can I automate?

I was talking to a colleague about implementing this kind of a control in a conversation in the office and I came up with something like this:

Figure 3 – A control service

Figure 3 was a quick view drawn to support a conversation, during a conversation. Its not a complete architecture but it does show some elements we can use to control authentication at an application layer. This control would be fairly easy to scale because it doesn’t rely on any person to check it. It leverages policies in active directory, and in this simple example I was demonstrating that we need a mechanism that shows continuous control.

You can see I was showing that we do not just need an authentication mechanism but we also need a mechanism to ensure its applied – you can have the best burglar alarm in the world, but if you don’t switch it on, its useless.

The view doesn’t cover all the IT Aspects; In itself it raises other questions we would need to answer in other views; for example:

  • Where would we run the different application components?
  • Who supports this architecture?
  • How would it be deployed?
  • How are these things supporting business needs?
  • What are the motivations for this?
  • What are the Key Performance Indicators & How Would I Implement Them?

In my example I am showing an application level control service – I can also have business or technology layer control services. There’s also nothing to stop me realizing a security control with a number of different control services or a combination of them.

So Why Bring All This Up?

Controls are important. The point of this blog wasn’t so much to show how to properly design a control service, as it was to show that there are varying levels of control you can apply in architecture, and hopefully to get people to think more seriously about what applying a control actually means.

I have spoken about requirements realization before – I tend to think of controls in a similar way – it is not enough to say we have controls in place – we need to understand how we have controls in place.

Controls need to be considered as an integral part of architecture design, and should not be an afterthought. If you design controls into architecture audits become significantly cheaper, because you do not need to burn so much time hunting for answers to auditor questions – you are continuously ensuring a well designed solution which does not only satisfy the needs of the auditors but is also built to actually protect the Information running through our systems.

Keeping Promises To Customers

Its the most natural thing in the world to want to promise things to customers to keep them happy. This blog discusses the dangers of that.

There are a couple of scenario’s I have seen occur many times in my career. Sales and customer teams unintentionally causing harm while wanting to keep customers happy.

Keeping Promises – The Catch 22

There’s a circular downward spiral that can happen:

  1. Teams have trouble meeting customer expectations
  2. To make customers happy they make promises that are hard to keep.
  3. Because those promises were unrealistic, they loop back to step 1.

Its very important promises made to customers are realistic and can be delivered. For Example, If an architect says something will take 20 months to deliver, Its for a reason. A customer team should not agree with the customer to deliver in 12 months, without the solution design being revised.

Its important to re-plan because its most likely not as simple as throwing extra resources into a project or working overtime. Although efficient architecture can make scaling resources for projects a lot more cost effective, often architecture designs aren’t perfect which leads to a cost overhead. There are often dependencies at work. For example if an architect says migrations will take 2 week that estimate may have factored in things such as the amount of data that needs to be migrated and transfer speeds between systems.

If the customer needs to then do things in one week – the architect has to be consulted. It may be possible to meet the deadlines – but, for example, it may mean changes to the solution. Upgrades of hardware would mean extra costs, a different plan, or another mechanism for transferring data. Maybe using disks to transfer rather than over the network is an option. If you change the transfer mechanisms other risks come into play, and the impact on the end user may change.

Somebody Else’s Problem

Sometimes I have seen it where a the delivery team are just not consulted by the front facing sales or customer teams.

People are motivated to meet their own targets, and sometimes targets and goals for individual teams do not factor in a need to work together.

For example, a sales team may have annual sales targets. This can motivate them to make promises without considering the delivery consequence. If you measure and reward a team based on getting customers to sign they will do what it takes to achieve that.

It is a very different case if metrics are put in place to tie together the success of a sales and delivery team.

Adopting A Culture Of Collaboration

If a sales and customer team makes unreasonable promises, it will ultimately cause harm in a few different ways.

  1. Failing to deliver erodes trust; conversely becoming a trusted partner really opens up doors of opportunity.
  2. Putting delivery teams under excess pressure destroys morale – bad morale destroys productivity and you end up with long running projects that have very poor retention of staff. At this point if you don’t have good architecture in place your costs can also skyrocket as unnecessary meetings and fact finding missions start to happen as people need to catch up and be on-boarded onto a project.
  3. Costs also start to balloon because its likely that you end up customizing standard solutions when you don’t need to.

Its very important that sales and customer facing teams collaborate with architects. Don’t forget architects are there to solve problems, not create them. If a sales or delivery team is going to ignore or override what an architect tells them then that’s likely to have consequences.

Summing it up

A good architect designing architecture should be considering the needs of all the stakeholders and identifying risks to the different stakeholders as they happen. They are not there to make the life of the sales or customer team more difficult – although sometimes it can feel like that when they are pointing out lots of potential risks. There are internal risks of course that we do not expose out to customers, but its good to have an honest opinion.

There’s no shame being in a meeting with a customer and saying “I understand your needs, but before I commit to these deadlines I need to talk to my architect team”. There are sometimes times when sales need to agree to things to win a bid – but they should still talk things through with architects. Sometimes seemingly small things can significantly impact the viability of an entire business deal

I will end this blog just mentioning the importance of engaging architects all throughout a project. You do not want to leave architecture to the end of a project.

10 Issues In Implementing Large Scale Organization Change

This blog details 10 issues I have experienced in the past when organizations I have worked for, or with, have implemented large scale change

Recently the Company I work for Tieto announced a merge with Evry. We will become TietoEvry. Over the years I have seen many mistakes happen in different companies making large scale strategic or operational changes.

I would hope our organization avoids these issues in the run up to our new merger and I would hope anyone considers before implementing large scale change.

1. Planning Strategies

All too often I have seen big changes happen without proper planning; management have an idea, may have a few focus groups, or get outside consultancy and a new direction is born.

The big mistake can happen when this is done without fully understanding the impact of change, which is where enterprise architecture comes in. We have a whole range of skills around understanding business motivation, and analyzing business risk and change. Our modelling techniques when properly applied can enable us to help management understand the true impact of change. A good Enterprise Architect can act as the right hand of the business stakeholders.

If you build a strategy without involving enterprise architecture (and this does happen) then you may be limiting its effectiveness. You may be implementing an inefficient plan, or in some cases even an untenable one.

Its important to involve enterprise architects at the beginning of any planned organization change and throughout it. A good EA has tools, and insight into the change process and can provide all manner of methodologies that can help.

2. Solving the Big Problems

Before releasing a major direction change for a company its important to have solved the big problems – and to have a plan not only on what you want to do, but how it is you want to do it. In defining the plan to move forward its important to at least have a partial idea of where you are – understanding the current state helps you understand how to move forward into the future.

I previously wrote on planning work with Archimate – Fundamentally the concepts I introduce could be used, but with large scale change its important to start building strategic layer thinking. I would define current and future state architecture as well as the transition between them – in ArchiMate terms this would be defining plateaus and plenty of implementation architecture. The time you spend planning ahead of time is small compared to how fast you can burn time when nobody in the organisation has clear direction after a strategy announcement and just waits and sees what will happen.

A good approach is rather than just announcing change and stating it will happen, engaging teams before hand and get them to help. Taking a conversation where you say “We are assessing a number of options – if we take this option, what would be the impact to you – and what would we need to do to make it work?” will help you see pitfalls that may not of been evident and it also gives a level of engagement and commitment to an idea.

When merging companies, or making changes that will have major impacts on the jobs of employees, there are of course some limitations to how far you can take such an approach. Even if you cannot engage the entire company, a good enterprise architect will help.

3.The Aspects of Architecture

I have spoken about the IT Architecture Aspects before. As with all architecture changes, a new strategy necessitates us to think of our architecture aspects:

  • Processes & Roles
  • People & organization
  • Information & Governance
  • Tools & Technology

For each of those areas we effectively need to explore what, why, who, how and when. This can be approached with different levels of methodology. Some EA’s model these aspects using languages like ArchiMate and are able to give detailed analysis of the impact of change across the different aspects. Its very easy to miss key elements when you are not thinking about how the different aspects interact with each other.

4. Feeling Engaged

Its important for teams to have a solution minded approach to issues, rather than a problem minded one. I have to be careful with this one myself; I tend to think in terms of problems – not because I am negative, but you do need to identify a problem in order to be able to solve it. If a team has a problem the same team should also think about potential solutions, or we can handle it as an architecture concern.

Its amazing how a few individuals can derail the success of a strategy. At one point I started running a new architecture team that was implemented amidst many other changes. In order to manage the scale of change I decided I needed to engage a small core team of 5 architects and they would manage the larger team of around 100 people. I was distributing authority, because I am only one person. My plan would have worked well, except for one person. I would set direction for my team on a Monday morning, and in the afternoon the core team would set direction for everyone else.

What happened was one person in the afternoon meeting would complain about everything. Effectively that one person turned the entire strategic focus from being solution oriented, to being a firefighting one. It was negative and it was hard to get people engaged in creating a positive change. My core architects were stressed and every little thing then began to be questioned. Even more time was wasted.

In the end because I had to manage that problem and for a while my work was significantly increased. I didn’t allow this to continue for long, but my point is, that if I had known the trouble spot to begin with and taken efforts to get that guy on board with the new strategy, the strategy would have been faster and easier to implement. If one persons argues an hour in a meeting you invited 100 people to – you have lost 100 hrs of time and will have collateral damage.

There’s a balance to be had. Where you see a negative influence, you need to deal with it fast – preferably in a positive way. A passionate person can be your undoing, but when you manage to get the same person on board they can be your biggest advocate. Its good if you can identify passionate people up front.

5. Role Management

When I look at different companies and reasons for failure of strategy execution sometimes it can be traced back to Human Resources / Line management processes and adherence to them. Any job role has a set of expectations and those core role expectations are the ones that need to be assessed and measured. When this isn’t done what can happen is over time as the organization changes, roles change. This can give an enterprise architecture headache as you see an organization that appears to be fully staffed in different functions but in fact isn’t. When trying to decide a new team structure this can be a problem.

For example if technical specialists become architects without proper training and assessment you end up with a group of architects who will know technology but not have the skills to be able to fully describe an architecture or manage it. The transformation from role to role may have happened for a variety of reasons.

I once in the past came into a project with over 40 architects, of which none of them could actually describe architecture outside of creating basic technology views in Visio.

If you were to run a team with 100 architects, and you think the workload only needs half that, last thing you would want to discover is that in rationalizing teams you have broken other areas of the organization because the job those resources were actually doing was not what you thought at all. Before making such decisions its essential to really understand what all roles and responsibilities in the organization actually do.

6. Consistency in leadership

For change to be effective it needs to be understood and aligned within the leadership of a company. When a CEO announces a change of course everyone in management normally want to do the best to support it, but sometimes their own personal goals and targets can restrict this. IF a CEO gives a set of goals to hes leadership team the leadership team needs to filter those goals down to the level below them. and that level needs to cascade the relevant goals further down.

I have seen in the past in some companies goals at the top level that look very different to the lower levels. If a board member has 10 goals around growth, and development in different areas, but his/her direct report only has a financial target – much of what was intended will be lost. Even if PowerPoint presentations fly around the place with all the original board goals. Much of what is in PowerPoint gets forgotten over time. The formal review mechanisms need to include the goals from the board in some form; if you are expecting the subordinates to meet them. The formal review process is actually what impacts peoples earnings and career development.

In one company I created an architecture view that showed 5 levels of management together and their goals, and only financial goals existed below the third level. I asked my manager at the time why this was, and was told that the management didn’t want targets that they couldn’t easily measure, because it would impact their bonuses. This was bad.

If your HR processes are clear and measurable, and someone takes the time to ensure that goals are aligned as we filter down an organization then when change comes we can more clearly ensure that change is effective. Wen building a strategy clear expectations need to be laid out to every level of the organization and if need be working practices and processes revised.

7. Unclear HR

People tend to stick with doing what they are comfortable with but unless goals change and people understand their own personal role in a new strategy people will not be fully invested in it.

What can be worse is when the change then happens – often some roles disappear. This is where hero’s are born – and a hero in enterprise architecture is not always a good thing.

8. Heroes

Heroes do their best to mitigate the chaos around them by assuming the responsibilities of roles that do not belong to them and seemingly get things done. I have a love/hate relationship with this. I applaud the effort and intentions. However, this can break things in many ways for many reasons including:

  • Roles informally transform: if a role informally transforms it means you have created a deviation from the intended strategy; and the way the company is something else. Your organization is not running as intended.
  • Processes start to break: At this point you will start to detect the issue if your processes are properly measurable – because you will see they are not running as anticipated; the correct people are not doing the correct things. The outcome may appear to be good but the working practice is unlikely to be efficient, and where you aren’t following process you are likely creating risk
  • Understanding resourcing hot spots becomes impossible, because people are covering them up. For example if a sales team suddenly looses the services of a translation team, they may have people who can do the translations in their own team. If they do that without properly escalating out the fact they are doing that work there are a couple of possible issues –
    • Firstly they might not do the job as well as a professional service.
    • Secondly, they have then become unwittingly accountable for that translation.
    • Thirdly, they have added to their own workload and stress. I’ve seen this break good intentioned people.
    • Fourthly, The line manager may understand this change in role but if its not formally built into the role then in adding the responsibility to the resource means the focus is suddenly shifted from the intended job role to something that is invisible to the organisation on a whole. If that same resource is spending a week doing translations in a sales case, he is also spending a week not doing sales.
    • Fifthly, This isn’t scalable. If a sales resource is bridging the competency gap filled by another missing role in the organization bringing in another resource to assist won’t be as effective as it should. Different heroes will extend themselves in different ways and this becomes quickly immeasurable.

In bad situations I have seen line management become reliant on heroes. If you are a line manager and can only use one or two of your key resources for a specific task the chances are something is wrong. Either your operational processes are broken, or your HR processes are. As a line manager this has to be escalated and actions must be taken to rectify this, or what will happen is over time, you will lose your hero as they become overwhelmed; and you will be left with worse resources, until the quality of work becomes so low that the continuation of business is untenable.

This may sound a little controversial but we need to eliminate the need for heroes. If our strategy ensures we have clearly defined roles and KPIs, and we put in processes to ensure they are followed the need for heroes is significantly diminished.

Its important to be aware that having measurable KPI’s in an organization doesn’t mean you become any less flexible. It means you are keeping track of the things that matter. Its possible to have a good balance of discipline and flexibility.

The professional

I can imagine some people thinking what I said about Hero’s is wrong – because we all have responsibility to do what we can to further business right? Yes we do. but there’s a right way to do it. In an organisation I would say everyone has a responsibility to identify and escalate risk where they see it – I would also say, sometimes we do need to step outside our roles and get our hands dirty when its needed. Of course communication and collaboration is important. Collaborating with our coworkers to help them is important – but we should always be mindful of our own roles and goals, and of the process.

9. The Importance Of Process

Process is important because it enables us to scale, have common direction and measurement, whilst managing risk. Sometimes process is not well defined which needs to be addressed. When a professional escalates they do not normally just complain; its far better to offer a solution rather than a problem. Its also important to have perspective. Everyone thinks that their area of business is important, but its rarely as nearly as important as the business of the whole organisation.

Properly defined business interfaces need to exist between different parts of the organization, and between the organization and the outside world. All these things need to be measurable. If you are running a business with many service areas, as well as the underlying processes, you need overarching processes to hold those units together – not only the company level standard processes, but also processes that address the end to end needs of the customer.

When transforming the organization you need to also be considering from the outset how you are changing process. If a process is not communicated well, is difficult to follow, does not cover all the use cases necessary, or simply doesn’t work, or isn’t helpful these are all failures of process design that need to be addressed by a process team. Processes can be agile and flexible if they are well defined – they don’t have to be a monolithic. Process often gets a bad reputation because its often poorly designed and implemented.

10. Communicating Change

The first thing I would say about this, is do not talk down to your resources. Treat people with a level of respect and intelligence and they will, to an extent, do the same. Of course there are legal implications of what you can and cannot communicate, and over communicating can be problematic too. If you stress people to the point they are worried about their jobs efficiency goes down unless in the same time you are communicating exactly what needs to be done in order for people to keep them. A plan that is effectively designed between management and an EA will go a long way towards quietening discontent.

Having a plan defined with architects before announcing huge changes goes a long way to calming fears. A company can loose many man hours if they announce the change and then do not follow up with direction as to how the change will be handled and implemented quickly afterwards.

The direction “Business as Usual” has a limited effectiveness. Uncertainty is a productivity killer. People sometimes will worry – they will stall – they will be reluctant to implement some initiatives because they will be concerned of effectiveness.