Security design considerations

In the previous post ()we learned that when planning a security budget we have to deal with hidden costs, assets, process and a good quote of dealing with higher management.
The goal is to reach at least the mTCoS as i called it.

Now the problem I pointed out is that in order to define this target value we have to asset risks and rank them to be able to make choices.

This is a quite interesting topic per se, since it is still object of studies. I have seen several models to address the question, all have pro and vs, but basically are based on empirical experience, so the results are quite variable from author to author.

My personal experience on the field does not help me in the sense I have seen quite different approaches to the question, and a very little structured approach. The result was security implementation divided into compartments and a few coördination, even in big companies with cso and soc and the other things.

When we analyze a business process, we start defining the steps of the process, and the goals and the requirements. A similar approach is used in defining the security risks.

But while the business process is driven by our needs and interacts with the external world , security is driven by external drivers that are almost unpredictable, that interacts with our process.

Nevertheless we can make some assumptions using the thousands of reports and statistics that are available on the market on threats and risks. If we start to consider what those reports tell us we can make some interesting discovery.

What are the most common threats registered on the wild? Do not be surprised if in the first top we find sql injections, social engineering, credential hacks, phishing. The oldest techniques are still largely effective because the lack of a correct analysis of security risks that affects too many implementations.

It is incredible that till nowadays there are so poor security implementations, but the statistics tell us exactly this. Key basic features like strong authentication, encryption, log management are far to be widely implemented. And the same things happen when we talk about flow data control: categorization and standardization are implemented just when there are compliance requirements to local laws or mandatory standards.

This is not just related to the network realm, software suffers of even greatest security gaps than networks. A few is changed since when i was trying to explain that using security com+ methods was a requirement to anyone developing in widows environment. A few is changed in the .Net era, even if the security tools have expanded their realm.

Managing authentication, encryption of communications, data stored encryption, role and privilege definition inside software are widely not enough implemented.

Just as an example consider the just recent wide implementation of https, two factor authentication and a few set of other security options in widely used software like webmail or social networks.

After the Snowden affair we discovered that our data can be accessed and exposed by a wide large quantity of people, governments, criminal groups but still when we design security we start thinking just about firewall rules and a few other things.

The point is not if palo alto or fireeye are good products or not, and indeed they are terrific products if inserted in the correct security contexts, but if my security design needs those technologies, at what stage, with which prerequisites and how I have to manage and integrate them.

Dealing with APT without a SIEM as an example is just a sterile exercise and a waste of money, but worrying for APT without having a sound security implementation of authentication procedures, user training and a good response team is just as childish as dreaming to be a world’s champion without training and hard work.

A good security design requires a deep understanding of the processes that have to be securitized, a collection of potential point of failures related to the various aspect of the process, and an honest analysis of the requirements.

Legal constrains, environmental ones, technicalities and of course, economics have to be all taken into account. And sometimes would be more effective to warn that if a minimum level of requirements are not implemented other implementations are just useless as keeping the windows open while closing the door.