In depth security... what when the tables are turned?

With many new initiatives at governments and organisations in the area of security, I see that tables are being turned... and initiatives are lagging. Again.

Summarising

We all do our best keeping the baddies out of our systems, away of our data. But what if the baddies try to do the same? Trying to keep us out of our systems, away from our data? There's a new threat in town, it's our own systems.

Lately I have been talking a lot with one of the Information Risk Managers of one of my clients. Let's call him Frank, it makes writing this post a lot simpler.
So Frank is a different kind of Information Risk Manager. He's very much involved and active in product development. Frank's not policing, he's establishing policies in stead. Mind that I'm specifically not saying that he's writing policies, instead he's establishing them. Together with those around him that are supposed to live according to these policies, he is ensuring that every step of the way, they're involved. It's pretty cool. Then again, Frank is pretty cool.

Frank and I have been doing a couple of security awareness sessions at the client's site. These sessions revolve around Secure Software Development and the intention of these sessions is making sure that those that are developing the products know that they need to build in security from the start. Yes, we are only looking at IT peeps, even though security is obviously a business concern. Well, one step at a time.

I take it that you're well aware of OWASP's top 10. And likely you've at least heard somebody mentioning the GDPA, General Data Protection Act. And considering you're reading this post, you haven't lived under a rock in the past couple of years, so data breaches like the one at Equifax or Yahoo for that matter should be known facts by you.
I love it when these things are being discussed. Stolen passwords, accounts hacked, social engineering to get into systems. Examples galore to justify all those millions of Euro's and Dollars spend on security. Implementing all kinds of programs at enterprises and organisations. At one client I actually told the ISO (Information Security Officer) that his presentation on the topic leaned towards plain old terrorism considering how she was scaring the CFO to approve her budget request.
Well Frank is not like that. Instead Frank is explaining why awareness is so important. He's addressing it from a business benefit to do in-depth security, privacy by design and so on. I actually had to talk firmly to Frank and have a slide in his deck to convey the amount of vulnerabilities found in our systems in the past couple of months. Just to show that not doing anything is not an option. Reluctantly Frank complied.

At this client, we do threat modeling. We do Privacy Impact Analysis, Business Impact Analysis, etc. We analyse a lot. And we're moving into a way of doing all this such that the developers can keep on becoming more and more agile. Sprint based, epic-by-epic, one story at a time. Ensuring that nobody gets into the systems, privacy sensitive information is encrypted and transaction integrity is ensured.
Nobody gets in, and who's in can't see any data and those that can, won't be able to change is. It's awesome, it's secure. And it's lagging behind today's and more importantly tomorrow's threats.

We're spending so much time to lock things down, in depth, on all levels, by design. Making sure that there're no backdoors, systems are patched. But what about the threat of being locked out yourself?

Data hostage is the new trend. With the advent of biometrics, access to systems by certain individuals becomes more prevalent. Unless it's your iris, you won't get into the server room. Unless it's your fingerprint, you won't be able to unlock the device. With face recognition systems build into operating systems like Windows 10, iOS and Android you only have to look at your screen to be granted access to all that data.

Frank knows about all this stuff as well. Together with a couple of really smart developers he's working on utilizing this new tech to make security more convenient for employees that need to access on a regular basis, sensitive information from their devices. Multi-factor, with biometrics as a second factor is around the corner. It'll be all about what you know (PIN or password) and who the system recognises.

This makes it more and more interesting for cyber criminals to no longer try to get access to your data and instead prevent you to get access to your data. When we rely heavily on the uniqueness of our bodies. By storing precise information about a person's iris, face-metics, fingerprints and in the (near) future a person's DNA, we can ensure that people are uniquely identified. But what is going to happen when that data is compromised? 'Access Denied'.
In today's systems where identification is based on what you know and what you, we are nog focussing on corruption of passwords, PINs or authenticator apps. We're focussing on people not getting in, but we forget about people keeping us out. And when you can't get in, your systems are held hostage. Not only your data, which is typically the target of today's Ransom-ware.

We need to think of new architectures that also consider this aspect of security. It's the availability aspect of security. Data and systems need to be available, but consequently also accessible. Availability is typically associated with redundancy and clustering. Cloning and mirroring. On a more functional level it is associated with the GDPA views on a person's right to always access her data and the right to be forgotten. But what if access is denied? What if you're locked out?

Another interesting feat today is that once security is breached, users need to be informed. But what about the reverse. Your security wasn't breach in the sense that people gained access, but instead people removed your access?

This is new territory for many of us and I don't have a suitable solution for these kind of threats. What I do know is that you'll need to address this from your architecture. And you'll need to involve your Information Risk Manager from day one. And make her tag along full time. Constantly. Just like I talk with Frank on a steady basis. Sharing thoughts, discuss the philosophy of security and challenge each other on everything but mainly on how we can make everybody involved in the process of product development aware of these at times very interesting nuggets of architecture.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

The reason why IT architects fail, almost consistently, is modeling.

Summary: Because every architect will try to fit her solution in her specific model, the way architectures are created within a project is independent from each other. Thus within a project the application architecture is not really considered when creating the infrastructure architecture, nor is the data architecture or the security architecture. Consequently, creating an architecture for any business application is a waste of time. Or is it?

Probably, when you're like me an architect or like some people I know a project manager, you already know that involving an architect in your project, or acting as an architect in a project guarantees exactly two things:

1. The project will not deliver on time
2. The project will not stay within budget

Of course I'm just kidding, in fact you should be experiencing the exact opposite, involving an architect in your project or acting as an architect on a project, provided the architect is considered to be a project member and not somebody that can get a project out of a dire situation, means that the project is most likely delivered on time or as close as possible to it and all within budget or close to the budget. This is what the architect does and there's more. The architect will ensure that the deliverable will be of a higher quality and therefore be of more use once taken into production. The promised or predicted ROI (Return of Investment) from the business case is more realistic.

The reason why the architect is helping with this is not because she's architecting the deliverable, although she is, that doesn't really help. The reason is that the architect is the single one person in the project that is looking at the problem(s) at hand from a holistic point of view. Approaching from different angles and addressing issues with an open mind. Architects have the talent to think outside of the box, creativity is their key capability.

Still, architects almost all fail all the time in doing architecture, that is IT architects. Because this blog is about IT architects. The key reason here is that they are architecting within the boundaries of their area of expertise.

So what do I mean by all this. It's actually quite simple. Consider yourself in case you're an architect or that person in your project that is the architect. What kind of architect is she? Most likely, we're dealing with an application architect, an infrastructure architect, a security architect, a data architect, a UI architect, an information architect, a business architect or maybe even an enterprise architect. Point here is that within pretty much any serious business application, you're touching all of the areas discussed above. But hardly ever do you see an architecture that is integrating all of these areas into one single model.

Architects are working a model and in the best of cases, are handing their model to other architects to make them aware. The project manager has no clue of what's going on or dares to make any assumptions as to what is going on here. But the case in point is that the application architect creates the application's architecture, hopefully taking the input from the business architect to understand where in the various business processes the application is being used. 

Once the application architecture is done, the security architect is tasked to make it secure. This is when the application architect is not suffering from a god complex and doing all that security design afterwards himself. Obviously the data architect has no clue as to what is going on, because he's never involved. The application architect did all that work instead. Because, data is an integral part of the application, so...

This is where the architect is done and the project's developers take over. Best case scenario, the resulting application is close to what the architecture intended it to be. At least the application will adhere to some of the enterprise's standards, values and principles. Once all that development is over, the infrastructure architect is requested to, oh wait, best case scenario, the application architect is reviewing the application for compliance with the architecture, and this is when the infrastructure architect is to create the infrastructure architecture on which the application is deployed.

Okay almost the same scenario, but now the story starts with the infrastructure architecture and the application architecture is subjected to the infrastructure architecture.

Now do the same with a security architecture to start with and ...

In all these scenario's the different architectures are created as separate products. One is subjected to the other. There's really absolutely nothing holistic about it. There's nothing integral to it either. And it makes no sense when you think of it.

I will not make an analogy with architects of buildings or other physical structures because there is hardly an analogy.

The issue at hand here is, as I stated, that the different architectures are considered separate products, with hardly any coherence between them. For some weird and actually inconceivable reason, we're let to believe that a security architecture can be created separate from an application architecture and infrastructure architecture and data architecture and business architecture. This is of course complete nonsense. There is no way you can create a generic infrastructure architecture, not even a high level reference architecture without understanding the application that will have to run on it. Same for a data architecture. What's the point of having that without knowing the application of the data in a business process? There is none. Don't let anybody fool you, because it's just not there.

An important reason why we are working this way, is because we are let to believe that we need to work with models. Decent architects will at least not try to fit the world into their models, but every architect will work with models. Which makes sense because this allows them, us, to simplify the problem's solution. Understand the model and you understand why the solution works. But have you ever tried to come up with a model that covers all of the architectures mentioned before? A single model? Have you tried to draw a diagram that shows it all? And in case you tried, did you succeed? It's not possible because the perspectives, the points of view, the points of interest are different for each of the architectures. They operate, they concern themselves on different levels of abstractions and with different levels of detail.

Because all these models consist of different elements, different symbols is used on the diagrams and the level of abstraction is seemingly different, the architectures are done separately, in a logical order to the project manager, the enterprise's culture and the individual relationships between the architect. Key point is that the consistency between architectures is coincidental.

Hence, the creation of any architecture in the end is a waste of time, because none will hold when the project manager actually wants to deliver on time and within budget. Because he will sacrifice security over deadlines when it costs too much implementing the infrastructure according to the architecture. The data architecture is thrown out the window as soon as the application is not performing because of the database queries. Etc.

There is a solution to all this and that is to create a truly integrated and holistic architecture of the complete solution. Have all these architects work on a single architecture that encompasses all these different aspects and have a single solution architecture that addresses application composition, data structures, business processes, infrastructure and security consistently.

This requires that dogma is thrown out the window and reference architectures are basically just informed decisions on architecture principles and guidelines with architecture blueprints emanating from them.

But most importantly, it requires a model that covers every single aspect of an application. And I mean every single aspect. The model must and can only be a meta model. A definition of a business application defined in data elements and their inter-relationships (including cardinality, direction of traversion etc) that allows for the definition of every single aspect of any business application. This meta model is a data model.

And there's the key to the issue, the model we're having to deal with in order to make an architecture worth creating, is a data model. The different architectures we're used to having are just different views on that data model. This allows for various levels of abstraction with various level of detail, as however of interest to the reader.

Because the model is capable of capturing every aspect of the business application, the model is capable of capturing every aspect of a set of business applications, hence it allows us to capture the complete application landscape and hence consistency across the board, architecturally speaking that is.

Now why is this so important, what is the significance of having a single model for all architectures to be based on? The significance is in the fact that all of a sudden an architecture cannot be subjected to another architecture, because there is only one architecture. Consistency and coherence are a given, it is impossible to not have a concise architecture that is comprehensive and all encompassing because that would mean that part(s) of the architecture are not finished. Which is fine because it will have to be a conscious decision to omit these parts.

In addition, for application developers it will be counter-productive not to stay with the architecture, because that will mean that deployment in production will be harder, because every single aspect of the application is taken care of in the architecture. Thus allowing the developer to concentrate on quality, and consequently an improved ROI.

I hope you enjoyed this blog post, I for one want to thank you for reading it. I am aware that this post was quite long, but I hope worth your while reading it. Please leave any comments, agreements or disagreements as the more views there are, the better sight we all have,

Iwan

BYOD - Bring Your Own Disaster

Just to be clear, it's not a typo.
First of all, let me explain something. Over the past year or three I have heard a lot about BYOD and in most cases the acronym stood for Bring Your Own Device. And although I've been bringing my own device since very long, since about 2003 at several customers it has always been a problem to actually use my own device.
So yes, we've been able to bring our own devices, but actually using the device at our job doesn't really go beyond reading your email and accessing your calendar. Granted, sharing contacts between your device and the corporate is there as well.
I've had discussions with many subject matter experts from the leading software vendors regarding this topic (IBM, HP, CISCO, Microsoft), and interestingly enough the struck me that although they all have their tools ready to be sold to their customers to facilitate a BYOD policy, within their own ranks their policy was in all case more a matter of CYOD, or Choose Your Own Device.
Okay, so let's see what we're talking about here. Within the corporate environment there are basically 3 models possible (mind these are models):

1. Everything is provided by the enterprise. So you get your IT equipment from your employer and he takes care of everything, including payment of the hardware and its maintenance. You work in the office and that's where you keep your stuff. When your employer decides that you should be able to work from home, you get a laptop and you can work offline from home. Or in fact you can log into the corporate network using a VPN so you can access your files and maybe even your applications, although they're in most cases installed on your laptop. 


2. You get all the computer equipment you need and your employer handles everything. But because laptops are more expensive than desktops and because laptops are also harder to maintain, because you never know when they're available for maintenance, you're allowed to work from home on your own personal desktop and in case you've got a laptop... well that's even more practical as you can work from any location from which you can setup a VPN connection to the corporate network. Most likely you've installed some software yourself and by means of a USB drive or some other external storage. Hey, maybe even dropbox! You just have to make sure that you're running some OS that is supported by the companies admins and meanwhile you keep the anti-virus and other such software on your system.


3. Then as a last model, there's the option to use whatever device you have to connect to the corporate network and do whatever it is you do to accomplish your tasks. You connect to your employer's network through the internet, either via a wired, a wireless or a mobile connection. (Yes, I know that a mobile connection is also wireless). In this last model, you bring your own device and not so much your own computer. There's a big difference.

So now what's the relevance of all this. Well mainly it's got to do with risk. There are a number of different risks involved here that are less relevant in model 1, a bit more so in model 2 and significant in model 3.
So let's cut to the chase and do some business here. As we want to get onto the Disaster part of BYOD.

One of the more obvious risks of course in these models is the risk of data leakage. Both intended and unintended. With the topic of data leakage you're also bound to include leakage prevention and that is widely considered a security aspect of an IT environment. Apart from technology that can be applied, there is also a lot of organizationals aspects to this. I'm not getting into this. Not in this post.

The thing about Data Leakage Prevention from a technology perspective is all about control. Mainly control over where the data is stored and where data is communicated from and to. Basically, if you control where it is stored and you have full control over this location, you can just prevent anybody from accessing it and there's no risk of leakage... in an ideal world, I know. It also means that you control when it is accessed and if you control the communication lines, you also control what is communicated. Basically this is the strength of model 1. In model 2, you have less control over where it is stored and when and how data is communicated, but there are still plenty technologies and solutions available to apply sufficient control at an acceptable cost to prevent, to a degree, data leakage. A weak link in this chain is the fact that it is fairly simple to loose a USB drive and with that data. Whether intentionally or not.
It gets a bit more interesting when working on your own device. Yes you can loose that tablet or smartphone, but there's another thread that's more significant on your own device than it is on your own computer and that's the thread of malware.

The interesting part of devices is that they are technically not really mature. New devices are popping up every few months, new operating systems, new capabilities etc etc. And in addition to this, their storage is almost limitless, by that it is very limited. So most people that use devices also use cloud solutions for storing their data, in many cases the corporate's data.

But this is all just a matter of potential compromises and risk calculations. Yu accept the risk, there's no problem. But most companies can't handle certain data to get out on the street, or at least that's what they think.

Like I said, it's all risk based and security threads should be looked at from a risk perspective. Looked at from the perspective of what are the chances that it happens and what is lost when it happens. This requires a certain level of organizational maturity. A movement that has just started, hence not many organizations are ready to handle security in this way. Oh yes, they may have completely adopted the risk-base approach to security, but they're far from having classified all the threats and defined the proper counter measures to avert the threats or mitigate the risks. Thus 'Lock down' is still what happens, until we're ready, is what's being said.

Yup data leakage is a problem and with your own devices this is even more of a problem but predominantly because we want to lock our data down because we can't act on the security risks from a threat-classification perspective. So we put a lock on the data, which means we put a lock on the devices. And since it's your own device, your boss is putting a lock on your device... in vain in most cases as either the technology is not adequate or is not yet developed for your device. Ah, let's not forget about the variety of all devices. All the different PC operating systems, the various mobile platforms, the various versions of each platform, the capabilities of devices and the variety of ways they can connect.

The disaster kicks in when the CSO (Chief Security Officer) and her underlings are confident they're on top of it. Because they never are. And at the first breach of their defenses, typically moments after a device is brought into the organization, you've Brought Your Own Disaster. Mind that the breach doesn't have to be a disaster in itself, but a breach of security in an environment where threats are dealt with in throwing technology at them and lock things down, ... well you get the drift.

Data Leakage is interesting, but there's more to the disasters that can happen by Bringing Your Own Device.

Think about compliance. Who's going to pay for all the licenses of the software installed on your devices? And who is going to ensure that you work with the right versions or even applications? Even though there are open formats doesn't mean that they're completely embraced by enterprises. In fact, I know way more organizations that keep all files in proprietary formats like Microsoft Office formats, the old ones, instead of the open XML based formats. And this is just an example of programs for which there are open formats that are supported by free (as in free beer) programs.
Since it's your own device, you're supposed to get the licenses yourself in many cases. And why would you pay for them where you can get them for free (as in illegal downloading free) from the Piratebay? Btw, I don't condone piracy.
Yet, since you use those programs for your work and when in the office even within the corporate's network, there's a compliance issue.

Again, people responsible for the various security aspects in the enterprise, including compliance aspects want to take the risk-based approach to this, but until this is in place, they revert to technology to ensure that you won't have any non-compliannt, read pirated, software on your device. There's an interesting aspect to this; Typically there's a policy in place that's supposed to prevent you from putting pirated software on your device. This policy is defined in terms of technical counter measures based on some tool that will probe your device and delete everything it deems not in accordance with the policy. Of course this can only work when you device supports this, in every aspect, including you allowing it to support this.

Again, by putting pirated software in the office by means of bringing your own device into the office and use it to do your job, disaster has been brought to the office. True, this is also not always resulting in your employer's bankruptcy or something even more serious.
Actually, to be honest, the Disaster in Bring Your Own Disaster is not referring to the problems you're causing with your own device, it's the disaster of managing these devices, which is something that is just impossible at this point in time with technology, considering the multitude of devices, types of devices, operating systems, platforms, capabilities etc. It can only be handled by having implemented risked-based security. Which is something that requires a lot of organizational changes, and change in mindset as well.

This is why most enterprises are actually reverting to a Choose Your Own Device strategy. Out of a pre-selected and manageable set of devices ranging from phones to tablets to desktops and laptops, you're allowed to pick the ones you want to use, as an extension of the office.

Thanks for reading, and as always, please let me know your thoughts about this topic.

Iwan