Whenever someone in the IT department is asked “how secure” their system is, it’s always just the right answer for the asking party. Reality is another answer, one that can’t be answered with exactness. Kind of like that time you asked your priest where heaven was and what the gates were made of.
The answer probably induced the same feelings that the IT department just gave their supervisor. When people realize that most of the malicious intent was perpetrated by other IT professionals themselves, the metaphors change to something like a sci-fi war scene.
“Well, you see, there are good angels and bad angels. The bad angels have secret tunnel they dug with leftover wings found after the battle in heaven. With these access points, they run around inside heaven causing all sorts of mayhem. Only bad part is the bad ones look just like the good ones”.
Truth is, security is a dynamic problem. As in, new problems are always being invented. Complex systems tend to become more complex and to compound the problem, the people who set them up keep disappearing. New perspectives mean changing systems and jeopardizing old methods. Updates, upgrades, and introduction of new “features” just throw pinches of sand in your new bathing suit.
Just knowing the scope of security and a fraction of the available solutions is an expertise on its own. Therefore it becomes a daunting task to approach the topic of security as a whole and more palatable by taking small bit size parts and analyzing the problem/solution. For our closeup look today we are going to be exploring the idea in separation of services and why it might be more secure than running services together or on the same system.
Full disclosure, while many experts agree that sharing credentials, databases, and application resources can increase the possibility of entire system compromise, they also agree that this same separation can increase security if implemented correctly. What they are talking about is gross negligence to some easy fundamentals.
An example of poor security would be something like multiple applications accessing the same database using the same credentials.
Done correctly would be each application has specific credentials. Common sense. Where the idea of separation starts to take on new light is the example of credit card transactions.
Poor implementation would be putting the credit card numbers in the same database. Enhanced implementation would be to put the credit card number minus the last 4 and placing those last 4 digits in an entirely different database on a different server.
You could further increase the security by moving more of the data, such as card ownership to another service. Multiple layers mean opportunities to secure, encrypt, or authenticate. Each new layer is another level any wannabe hacker has to overcome.
A practical example would be how the security works in our lock product. In a lock application, you have several services and some potential vulnerability such as management, enrollment or key entry, validation, data storage, communication between readers and host. Starting from the top down.
Management is provided by a web accessible interface or API. Features of management include:
adding users, keys
read reporting systems
validate user access and encryption
Validation is a separate service that has multiple functions:
confirm incoming communication is coming from validated reader
validate incoming key request and confirm the user has access to the system resources
log entry in the logging system
access the hardware such as relays
Data store is provided by database and is responsible for:
validating which service is accessing database
encrypt stored data
An application of this complexity could have been made in a single service. All functions encapsulated into a single interface that allowed for full access to the systems entirety. Security could be simple. But the issue of a compromise at any level means the system itself is compromised.
What we have done is increased the level of complexity but allowed for multiple levels of security which means that a compromise at one level doesn’t necessarily mean a collapse of all systems.