Role of abstraction in security

Abstraction and Security

Everything in the world you see and interact with are abstractions. You see a tall building where you have your team dinner and enjoy the evening, In that tall building, you do not have to care about the building is going to fall on you or dinner would not be available for you and your team. This whole complex of tall buildings involves the construction of buildings using infrastructure materials, aesthetics and music that are abstracted to you such that you could use them for the purposes it was made.

Cynefin framework categories the systems across 4 key states, from simple to complicated to complex to chaos. It is focused on predictability and orderness of the system. Abstraction converts Complicated systems to simplicity and easiness. In Technology, you are given an abstracted library for its purposes where you would not care how things work inside. Let’s say you have to review the library, how do you review it? you have to see the source code if available and run security scans. This is like going to a restaurant and seeing their kitchen and testing that all materials used for cooking are not expired and are safe for consumption, are we going to do it? How do we trust it then? We are going to trust them via audited FSAI ( Food Authority System in India). Audits are abstractions of saying that the library or system is secure and can be used. For internal audits and testing, if you give an abstracted system to the security team, they will be unable to review it. To review/ test it, we have to unabstract them, leak or understand their complications to evaluate security standards. complicatedness is subjective. It depends on the system that is abstracted or it depends on the person who is looking into it.

Blackbox testing is tested on abstracted software whereas whitebox testing is to unravel the abstracted software and test their complexities. This is one of the cons of abstraction related to security, an abstracted software would not reveal any faults/errors. To validate it, we have to leak their abstracted software and their complexities. To do that, it needs an understanding of that complexity, which takes effort and time.

Abstraction should not be leaky

Abstractions becomes a leaky one when it does not provide what it was made for. Security Defaults are abstracted security packages given to developers such that they should not worry about security but what about other factors, Do secure defaults affect performance, scalability, cost, reliability and operational issues? Security defaults should be validated and trade-offs should be visible for developers or else it will be leaky and they will not have the confidence to deploy

CVSS Score fails at showcasing its true purpose because the scoring is a leaking abstraction. The abstracted score does not do what it’s actually for which is prioritising vulnerabilities. It is abstracted to show you a score on the impact and possibility of the attack but since many vulnerabilities are falling under the same score, the intersections are more and we have to rely on other factors to prioritise the vulnerabilities. It is abstracted so much that we did not know how to calculate one or understand what the CVSS 7 score means. Too much abstraction will defeat its purpose.

Security confidence is achieved when we are not leaking abstraction and understanding its complexities. If it is leaking, the abstraction is not good, improve the abstraction to provide confidence. For example, once you test an abstracted software, you do not have to do it again.

References