There is old Indian fable about how an elephant looks like to the blind men in the room, the person who touched the trunk of elephant described it as a snake, the person who feels side perceived it as a wall, who touches the ears identified it as fan and story go on …

A great many people like blind men in a story do not think about security holistically and cyber security is a whole new elephant to analyze.

Hackers are working around the clock to keep ahead of the competition to make as much money as possible. The sophisticated attacks, with business-minded infrastructure, make ransomware like WannaCry and NotPetya — which locked up devices at multi-billion-dollar companies — look like imposters.

With increasing attack vector and effectiveness of the attacks, the damage done to business and government is not limited to only disrupting the services or stealing the information but the latest attacks are capable of damaging the physical infrastructure and creating the war like situations.

The department of Homeland Security’s Industrial Control Systems Cyber Emergency Response Team report states, it has never seen so many successful exploitation attacks on the Industrial systems.

The time has come to look at the security holistically from the inception of system till it is disposed of securely.  When we talk about system, we should consider not only hardware, OS but the application deployed on the top of OS, the access provided to these application through the various means like, the internet, intranet, mobile, types of user and end devices accessing the application and hosting facilities like public cloud, private cloud.

This is where the security engineering comes into the picture

“The mantra of any good security engineer is: ‘Security is a not a product, but a process.’ It’s more than designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together.”

–  Bruce Schneider, Cryptographer and Computer Security Expert

The security should not be after thought but should be an integral part of system design. To build robust security the security design principles developed by Jerome H. Seltzers and  Michael D. Schroeder in 1975 are still applicable.

In this article, we have provided Saltzer and Schroeder’ design principles and few additional principles relevant to current protection requirements.

Principle 1 – Economy of Mechanism – Simple design is easier to test and validate. If a design and implementation are simple, fewer chances to make errors. The testing and validation process is less complex because fewer system components and use cases to be tested. Complex systems mechanism often make assumptions about the system and environment in which they run. If these assumptions are incorrect, security problems may result.

Principle 2 – Failsafe default – Deny access or shutdown application in the case of failures. The default access to system is none. Whenever access, privileges, or some security-related attribute is not explicitly granted, it should be denied. Moreover, if the user is unable to complete its action, it should undo those changes it made in the security state of the system before it terminates.

Principle 3 – Complete Mediation – All access (physical or logical) to the system should be validated before granting access, no cashing for access related information

Principle 4 – Secure weakest link – Security is chain of controls, chain is as strong as weakest link

Principle 5 – Defense in Depth – Multiple layers of security, this strategy was originally used in the military by creating layers of defense that compel the attacker to expend a large amount of resources, while straining supply lines. The goal is to delay and render the enemy attack unsustainable. This strategy results in leaving the attacker vulnerable to counter attack.

Principle 6 – Least Privileges – The means giving a user account only those privileges which are essential to perform its intended function. For example, a user account for the sole purpose of creating backups does not need to install software: hence, it has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked.

Principle 7 – Separation of duties – Make sure that maker is not a checker, this only means people who are entering data are also not validating it.

Principle 8 – Least or no trust – Assume that everything can be breached and define the incident management processes and recovery plan defined and tested for faster recovery from the breach.

Principle 9 – Least common mechanism or sharing of resources – Sharing resources provides a channel along which information can be transmitted, and so such sharing should be minimized. No sharing of account or user names. If two people need to work on the same data create two user accounts.

Principle 10 – Noting is secure – Hackers are always ten steps ahead of protectors, they are having state of the art tools and motive to break into your systems. Take multiple back-ups of data and store offline and offsite

Principle 11 – Generate awareness – Users are the weakest link in the security chain, generate awareness and make users accountable for their actions

Principle – 12 – Logging and auditing – system should be able to generate logs and should have mechanism to define alerts for monitoring deviations

Principle 13 – Preform risk analysis – Nothing is foolproof, identify the vulnerabilities in your design and mitigate, if not possible, accept it and define mechanism monitor these vulnerabilities closely to get early signs of attack

Principle 14 – Psychological Acceptability – Deployment and Configuring of systems should be as easy and as intuitive as possible, and any output should be clear, direct, and useful. If the security-related software is too complicated to configure, system administrators may unintentionally set up the software in a not- secure manner. Security-related user programs must be easy to use, minimum intrusive and cannot be disabled without privileged access.