Thinking Security: Is This Still Good?

 Author(s): , Posted on June 9th, 2016

This is the 17th blog in a series about security and how security is about how you think.

In this blog, we’ll concentrate on the third goal of security: Data Integrity. In its broadest sense, this goal is to make sure that each item is the exact way that we expect it to be and that we can see if it’s been changed. This is important from a security point of view because we need to be able to trust that an item/object hasn’t been modified since the last time that we examined it. This could be a simple as when we receive a letter, we check to make sure that the envelope wasn’t opened. We also want to make sure that the contents haven’t been changed, deleted, or replaced, and we start to do that from noticing that the envelope hasn’t been opened. We may also want to be able to determine that the envelope hasn’t been opened and resealed (must tougher to do, but to really trust that the contents weren’t changed, then we would have to be able to do this) or that it was a new envelope.

Now, let’s take these ideas larger – how do I know that my house (an analogy that I’ve used throughout this blog) is exactly the same as when I left this morning? How do I know that someone hasn’t opened my front door and looked around, moved my fancy Internet-connected toaster, and left? How do I know that all of the mail that came through the slot in the door hasn’t been modified (and how do I know that it came from the person or company that it says it came from)? How do I know that the latest download for my Internet-connected toaster hasn’t been hacked?

The goal of data integrity needs many mechanisms in order to prove that the data that we care about hasn’t been changed. One of the simplest is a “checksum” – a unique number found by some algorithm which gives us a number which corresponds to the data that we can check again by performing a checksum on the current data and see if the two checksums agree. The more intense the algorithm (we’ll call this the “strength” of the checksum), the more likely that changes in the data will cause a change in the checksum. For example, if the checksum is just whether the data is odd or even, it won’t catch if I change two bits in the data, but other stronger checksum algorithms would. If this process also includes something which identifies the owner, we call this a “signature”. By using signatures, we can authenticate prove the person who sent the data to us as well as prove that it hasn’t been changed.

But data integrity goes much further than simple algorithms on data. Let’s revisit the house analogy again. The way that the builders thought as they built the house contributes to how it helps ensure that its contents (and itself) haven’t been changed. By putting all of the screws on the inside of the house, doors can’t be taken off their hinges, windows can’t be taken off to be used as gateways into the home. The integrity of the home really comes down to how it was designed and architected as well and how the designers thought about security. This shows that true security is more than common mechanisms – it’s about how it was designed and architected.

This is why ClearPath Forward mission-critical servers lead the industry in data integrity – it’s the way that the “house” was built. The same break-in techniques that can be used regularly and successfully on other commodity machines (such as buffer overflow, stack modification, data execution, etc.) don’t work on the ClearPath Forward environments (both MCP and OS2200) because of the way that the designers and builders of the systems thought and continue to think about security.

For example, looking at the ClearPath MCP’s memory architecture – there are no pointers – there are memory “objects” that applications use for data. This architecture ensures that all references are bounds checked, and therefore no buffer overflows can occur. Looking at the ClearPath OS 2200’s memory architecture, it has a concept of separated code and data. This architecture ensures that data cannot be executed (that data space cannot be loaded into the processor). This aspect of the OS 2200 architecture ensures that stack modification and code execution cannot occur. These concepts are analogous to the concepts of putting all of the screws on the inside of the house, so that common break-in techniques just cannot occur.

Data integrity is one of the most important goals of security because it ensures that data and systems haven’t been changed and can be trusted with important data – whether that data is mission-critical data or the information which makes up your life. It also boils down to how you think about the data itself – from simple checksums to determine if something was changed to the whole architecture of the house or mission-critical computer system which defines the security of the entire system.

For more details on how ClearPath Forward systems ensure data integrity, please reference these white papers: ClearPath Forward MCP and ClearPath Forward 2200.

Tags: , , , , ,


About the Author

Mike Kain is a consulting engineer and security architect for the ClearPath MCP environment and has held various technical leadership positions during his 30 years of experience at Unisys. Read all Posts





«Unisys & Equinix join forces @LDNTechWeek

SIAM – Practical Fashion or Emperor’s New Clothes? »






We use cookies on this site. By using this site, you agree to our use of cookies. To change or learn more, see our Privacy Notice.