Listen, We Need to Talk About your Attack Surface

Listen, We Need to Talk About your Attack Surface

As Miguel de Cervantes wisely said, “Never put all your eggs in one basket.”   Yet, when we design our software for IoT in one large, cumbersome, monolithic stack – well, that is exactly what we are doing.

And it all comes down to the attack surface.

For a software platform, the attack surface describes all the different points where an attacker could get into a system, and where they could get data out. The attack surface of an application, therefore, includes all of the following:

  • the sum of all paths for data/commands into and out of the application;
  • the code that protects these paths (including resource connection and authentication, authorization, activity logging, data validation and encoding);
  • all valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data and PII;
  • the code that protects the data, including encryption and checksums, access auditing, and data integrity and operational security controls.

Traditionally, we’ve thought of attack surface as it relates to perimeter.  After all, a perimeter is easy to think about as an area that needs to be patrolled and/or protected from harm by a bad actor.  And so, it’s always been important to protect the perimeter.

On the surface (no pun intended), that makes sense. Consider this analogy. If we had one, big, monolithic building that measured 10×5, then we would have a perimeter to be patrolled of a total of 30 units (2x (10+5)).   Now if I carved up my monolithic building into a series of 25 smaller modularized buildings that measure 2×1 that would equal a total perimeter of 150 units (25x(2x (2+1))). Now, if I told you that having 25 modular buildings would be more secure than 1 monolithic building – would that even be worthy of a discussion?  Nope – your attack surface is 400% larger!! Think of all the added work you would have to do just to protect that expanded perimeter.

The problem with that logic is that in the world of software a modular approach is much more secure than a monolithic approach.

Under the leadership of Dr. Gernot Heiser, he and two of his undergraduate students performed an analysis in order to prove out this approach. They developed a modular system built on sel4 and were able to completely eliminate 40% of the critical threats from the Common Vulnerability Assessments (CVE) database, while mitigating a further 59% to one degree or another.  Click Here to Read the White Paper.  

Why does this counterintuitive logic on attack surface work? Simple – instead of one key to the whole house, you need to have 25 keys…and even then each of the 25 modules only has access to the minimum number of services required to do its job, and no others.  By using microkernels, one can support this approach to architecting a fully modular design. This means a breach of the perimeter of one microkernel does not compromise the entirety of the system.

So, in spite of the increase in the size of your perimeter (aka attack surface) – one can cut the risk to their IoT device through a modular approach using only their required resources to deliver a more secure system.   Or put another way – go ahead and put your eggs in many baskets.