Architecting Secure Information Systems
We have heard for years that security needs to be integrated into a system from conception, because bolt-on security is simply not as effective. So you have struggled with, bargained with and pled with system owners and developers to include security at the beginning of a process. Then you get that first invite to an architecture meeting for a proposed system. “Uh oh,” you think, “now what?”
Creating secure systems from the ground up is a different proposition, and requires different skills than buying and bolting on technologies to implement security after the fact. You have the chance to build this new system with a strong foundation. Do not miss your chance to show how security should be addressed. Here are a few tips for security architecture.
The very first step is determining what is the data or system you need to protect. Are we talking about an HR database that holds sensitive employee financial and health records, an online store that accepts credit cards, or is it a knowledge base that will hold solutions for common technical problems handled by customers and support staff?
The answer to this question becomes the central focus of your security. It’s the gold in Fort Knox, the Coke recipe, or the search-engine capabilities for Google. The rest of your security planning should be focused like a laser on defending this commodity.
What are the confidentiality, integrity and availability (CIA) requirements for your system? Every system has unique needs. You will need to work with the business to come up with the answers to these questions for this system. Ask the business owner questions like: What is the effect if this data were leaked to the public? How would we be affected if this data were changed maliciously or inadvertently? What would be the result if this system were unavailable for a few minutes, hours, days or weeks?
The responses from the business give us the framework for crafting this system’s unique CIA triangle.
- The HR database may have extremely high requirements around confidentiality and integrity due to the sensitivity and criticality of the data, but lower requirements on up-time, because HR can do without the system for a few days.
- The online store will have extremely high requirements on all three. Confidentiality must be maintained for credit card numbers, integrity of the shopping transaction is essential to ensuring we deliver the right merchandise to the right customer at the right price, and available is critical to providing a dependable resource for repeat customers.
- The knowledge base may have lax requirements around confidentiality because the data holds no sensitive information, but has strict integrity and availability needs because customers cannot be helped if these systems are unavailable.
Convert our CIA needs into detailed security requirements for the system. Now that we know the basic needs of our system, we can convert those needs into usable requirements. Take each CIA section and break it down into smaller parts. We’ll use the HR database as an example; here are a few of the requirements that can be broken out for this project.
- (Confidentiality) Ensure appropriate authentication methods are in place to allow only authorized users.
- (Confidentiality) Ensure authorized users can access only the data to which they are specifically granted permission.
- (Integrity) Implement granular permissions to ensure users can only edit data to which they should have access.
- (Integrity) Perform data hashing to ensure data remains consistent and has not been changed on the system or in data storage.
- (Availability) Store backups off-site with retrieval available within 3 days.
- (Availability) Provision appropriate hardware to support 3 day rebuild time.
These requirements should be used to evaluate the appropriateness and effectiveness of security measures for the system. The actual measures themselves can take many forms, including (but not limited to) custom development, third party tools, and administrative processes.
We can get so used to working only on production systems, that we are unprepared to do it the right way. When you finally get the chance to work on creating a system from scratch, make sure you are bringing value to the process. Help determine what we are defending, from what, and how. By getting these objectives outlined and understood early on we go from a reactive to a proactive team. This saves us developer and administrator time, money and a lot of arguments later on.
Connect with Robb on Google+