IT security covers the security of your Information Technology. A natural subset of IT security is information security - secure your information, in this context, as part of an IT system. I often argue that nothing is as easy to sell as fear. Fear of anything. Fear of lacking IT security and Information Security is no different. It is an easy sell. You just open with the line, “Are you sure your data is secure – because I think it might not be?” Deal! Show me! Help me!

In my opinion, these are the obvious IT security hygienic must-haves:

• Make sure you authenticate users.
• Have an order to your authorization processes.
• Keep your computers clean from unwanted software.

Beyond the obvious IT security must-haves, the delivered “Show me”, or “Help me” very seldom come to any real practical effect, other than “You should not have data worth stealing – and if you do, you should not let anyone come near it – not even your staff”. Well, thank you, Mr. IT-security expert. Not helpful at all.

From my experience in business, government, and military, the latter two take IT security painfully seriously. This does not automatically mean that they are safe, but they spend a lot of effort aiming to be safe.

There is a tradeoff between protecting data and making it easy for trusted users to work with data. You must find a level in this tradeoff that reduces risk and does not come in the way of work. There is no such thing as eliminating risk. Trying to eliminate risk will paralyze you and you will get nothing done. Decide what risk level is acceptable – and note that this level may contrast with the different types of data that you have. The risk level may also vary not only on data type and data value but also on data aggregation; you want to protect all the data more than the individual parts.

The Basics of IT Security

It is pretty simple really. Think of a PC as a piece of luggage at the airport. “Sir, did you pack this bag yourself? Have you watched it all the time since you closed it? Can you guarantee that there is nothing in here you received from others?” When it comes to your laptop – or the laptop you got from work – you must say “No!” Your computer is not to be trusted. Period. This does not mean that there is anything wrong with it, but we cannot be sure. It is easy to sell this kind of fear.

When it comes to the servers for your company that are placed under lock and key – patched and maintained by educated personnel – we might say “Well, we sure hope we did not receive anything we did not want.” So your servers might be safe – and they are easier to trust than user-pcs.

IT departments will try to toughen your PC up. Again, with the luggage metaphor, they might make it solid, making it impossible to store anything inside, safer – but you are not helped by a solid piece of luggage or a computer you cannot store anything in. Anything in between fully functional and solid is possible, but they can only do so much, and almost anything they do limits the degree of freedom you have with the computer.

The IT department is most afraid that your computer contains Trojan software that infects others at work – and increases the threat against the servers. Trojans can act as beach-heads inside your company from which hackers may have a line of sight to your servers. Trojans may also be a nuance or even hold your computer for ransom – but a professional attacking Trojan says nothing; it just steals your data – for weeks or years.

Once infected, it is really hard to trust a complex IT environment again because there are so many places where the Trojans may “hide” during cleaning. The cleaning will be extensive and this motivates great precautions to avoid infection. This text, however, will not deal with that kind of IT security. I just had to state the facts, to make sure we are on the same page. This text is about how we should build systems in this corrosive and hostile environment to control the risk as we expose our data to authorized users.

Building Safer Software Systems

The thing with building protected software systems is that part of the software will implement the lock that protects it. I will call “the lock” the AccessControlSystem. If the Access Control System protects the data from being exposed to the wrong user – then who protects the AccessControlSystem from being bypassed? This is the heart of the matter.

Did someone tell you that your system is protected by the Active Directory in your company? Wrong – the ActiveDirectory may be the one handing out the keys to the lock – but the system itself is responsible for implementing the lock. An Access Control System is almost always part of the system itself (true for all nontrivial access control), just like the lock on your front door is mounted as a part of the door. So what is the best way to protect the lock? Let the lock stay on the server! This is the conclusion that most software architects have reached. Since the lock is a part of the system – the system must stay on the server as well. This is the main reason for moving away from rich fat clients on Windows to a typically worse user experience with web technology like MVC even for in-house systems. Another way to keep the system on the server is to use terminal server solutions.

The important thing is that the Access Control System filters out the slice of data that is acceptable to show an individually authenticated user. Filtering out means that you have a bigger volume to filter from – a volume to reduce to a subset. The larger volume is what the Access Control System protects. If the Access Control System is going to protect this volume and filter ok data from it, then it must have access to the whole. This is simple logic.

Having stated these facts, we have a clear view of our goal: to deliver approved slices of data to authenticated users – our users are not physically on the servers – they are on their laptops.

Although the MVC web approach does this, many have found the reduced user experience is not ideal for prolonged use in an office. Bulky postbacks and the tendency to reduce the amount of data on a single screen to avoid lags often make web-based systems click-intensive and filled with stressful waiting. To mitigate this, many software architects have started to use Ajax and Javascript to build a richer user experience to replace the plain data presentation offered by MVC. When doing so, they might start to hold data locally in the browser, and gradually, they may start to lose track of our simple goal – maybe implementing filtering in the browser – maybe keeping data between screen navigations – maybe doing some work that was already part of the Access Control System. No one is certain, because it is difficult to see what a software system does without high-effort reviewing of actual code.

How MDriven Turnkey Does It – Every Time

To avoid the risk of muddling the definition of the Access Control System while still offering a rich user experience, MDriven Turnkey does 4 things:

1. Lets the ViewModel define the slice of data we agree with showing an authenticated user with authorization for a specific use case. The user cannot see more by definition in the framework.
2. Lets the ViewModel reduction of data from the complete model happen on the server and since each ViewModel is fully implemented with the declarative Object Constraints Language (OCL), you also have an exact and easily understood definition of the information subset it contains.
3. Defines the rules that build up the Access Control Systems in the model declaratively – with static verification – and the ability to make the rules depend on any data in your model.
4. Streams the resulting slice of data – and any changes to it – to a client to produce a rich client experience without slow roundtrips and exposes nothing else.

MDriven Turnkey comes with the Access Control System already in place – on the server – you merely need to define your keys depending on your rules based on your model. Even if you build a WPF, AngularJS, or Android client – the Access Control System is on the server adhering to your rules.

Since the platform has the Access Control System in-built, developers can make fewer mistakes. The verification of the rules can now be done statically in the model and we do not need to review code to detect the tendencies of muddling the simple goal of ensuring information filtering is happening on the server only. MDriven Turnkey user authentication is done with standard OAuth2 allowing for implementations with optional social login or Single sign-on (SSO) with OpenId. Multifactor authentication can easily be made part of your Access Control System.

Server-to-server authentication using OAuth2 is also supported as shown here.

All communication is done over SSL and if you have stronger crypto needs, any tunnel can be used to protect traffic between the user and server.

We claim two important things:

• Building software systems with MDriven Turnkey will make them intrinsically safe – meaning that even the lowest effort will expose only what you intend to expose.
• Using MDriven Turnkey will make your complete Access Control System possible to inspect even for non-coders – meaning that security officers can understand what risk level individual screens pose even in an evolving system.

Both these properties are highly sought after by organizations striving to minimize the risk of unwanted information leakage – whether it is from coding mistakes, architectural mistakes, misinterpreted requirements, or simply plain laziness of either developers or reviewers.

The MDriven Book - Next Chapter: Access control system in MDriven