Information security
No edit summary
Line 43: Line 43:
Since the platform has the AccessControlSystem built in the number of mistakes a developer can do are fewer. The verification of the rules can now be done statically in the model and we do not need to review code to detect 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 AccessControlSystem.
Since the platform has the AccessControlSystem built in the number of mistakes a developer can do are fewer. The verification of the rules can now be done statically in the model and we do not need to review code to detect 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 AccessControlSystem.


Server to server authentication using OAuth2 is also supported as shown here   
Server to server authentication using OAuth2 is also supported as shown [[Oauth2|here]]  


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

Revision as of 15:00, 10 March 2019

IT-security covers 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 really 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 really authenticate users
  • have order in your authorization processes
  • keep your computers clean from unwanted software

But beyond the obvious IT-security must haves - the delivered “Show me”, “Help me” very seldom comes 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. Really not helpful.

I have experience from business, government and military – the latter two take IT security painfully serious. That does not automatically equal 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 the trusted users to work with data. You must find a level in this tradeoff that reduce 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 then you will get nothing done. Decide what risk level that is acceptable – and note that this level may be different for 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 the whole of 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 on the airport. “Sir did you pack this bag yourself? Have you watched over it all the time since you closed it? Can you assure 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!” So 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-pc’s.

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. And anything in between fully functional and solid is possible – but they can only do so much – and almost anything they do limits the degrees 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 increase the threat against the servers. Trojans can act as beach-heads inside your company from were hackers 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 steal 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 really expensive – and this motivates high precautions to avoid infection. But this text 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 how we should build systems in this corrosive and hostile environment in order to control the risk as we expose our data for 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 AccessControlSystem 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 ActiveDirectory 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 AccessControlSystem 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 how do we protect the lock best? Let the lock stay on the server! This is the conclusion that most software architects has reached. Since the lock is a part of the system – the system must stay on the server as well. I think that this is the main reason for moving away from rich fat clients on windows to typically a 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 it is the AccessControlSystem that filters out the slice of data that we are ok with showing to an individual authenticated user. Filtering out means that you have a bigger volume to filter from – a volume to reduce to a subset. It is this larger volume that the AccessControlSystem protects. If the AccessControlSystem is going to protect this volume and filter ok data from it – then it must have access to the whole – simple logic.

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

Sure MVC-web-approach does just this – but as many have found the reduced user experience is not ideal for prolonged use in an office. Bulky postbacks and tendency to reduce the amount of data on a single screen to avoid lag often make web based systems click intensive filled with stressful waiting. To mitigate this many software architects has 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 ever so slightly 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 really was part of the AccessControlSystem. But who really knows – because it is really difficult to see what a software system actually does without high effort reviewing of actual code.

How MDriven Turnkey does it – every time

To avoid the risk to muddle the definition of the AccessControlSystem but still offer a rich user experience MDriven Turnkey does 4 things:

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

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

Since the platform has the AccessControlSystem built in the number of mistakes a developer can do are fewer. The verification of the rules can now be done statically in the model and we do not need to review code to detect 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 AccessControlSystem.

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 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 expose only what you intend to expose
  • Using MDriven Turnkey will make your complete AccessControlSystem 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 for organizations striving to minimize risk of unwanted information leakage – be it from coding mistakes, architectural mistakes, misinterpreted requirements or just plain laziness of either developers or reviewers.

This page was edited 43 days ago on 02/14/2024. What links here