Showing posts with label security strategy. Show all posts
Showing posts with label security strategy. Show all posts

Monday, September 1, 2025

Attack Surface Managment

 Thanks to our colleague, Ben Carr, for the idea and the title of this post.  I wrote most of what follows in response to a post of his on LinkedIn

The attack surface of the typical enterprise includes all the users as well as all the other resources.

I think about the desktop where most of the vulnerabilities are in system code, system code that dwarfs the applications.

I think about all the applications that are on that system that are rarely if ever used.  

I think about the orphan data and servers.

I think about the excess privileges that permit entire enterprises to be compromised starting with one user who clicks on bait in an e-mail or on a web page that he visits out of curiosity.  


So, one way to manage the attack surface is to reduce it.

  • Remove unused user IDs.  Reverify and reauthorize users at least annually.  
  • Remove unused or rarely used applications or services.
  • Install only what you really need.
  • Prefer purpose-built apps to general and flexible facilities (e.g., browsers, spread-sheets, word processors).
  • Hide systems, applications, services, and sensitive data behind firewalls and end-to-end application-layer encryption.
  • Employee restrictive access control (i.e., least privilege, zero-trust, "white-list") at all layers
  • Scan and patch only what is left (i.e., that which can be seen by potentially hostile people and  processes).
  • Other.

Tuesday, October 13, 2015

A Leapfrog Enterprise Security Strategy

Recently I was quoted in an article on newly reported, but somewhat old, breaches.  In the report I was quoted as suggesting that these breaches suggest that security has fallen behind and that, just in order to catch up, we need a "leapfrog" strategy.  This post will suggest what such a strategy might contain.

Mine would start with strong authentication close to the users, i.e., at the end point. Strong authentication will start with privileged users and move to all employees. We have known about the limitations of passwords and what to do about them for thirty years. It is way past time to get on with it. Going forward, the end point of choice will be the mobile computer, colloquially referred to as a "smartphone."  This device already contains powerful sensors that can be used for authentication of claims to identity.  Apple Touch ID and Samsung Face Unlock are simply early examples of what can be done.  These are quick and easy to use and, in combination with possession of the device, constitute strong authentication.  

My strategy would include reducing the number of privileged users, the reduction of their privileges, and accountability for the use and exercise of privileges. It would include involving two or more people in the exercise of sensitive but rarely used privileges. We have too many privileged users and too little visibility into how those privileges are used.
It would include the automatic notification of the subjects of records and the owners and managers of accounts of all use, changes to, or transactions against those records or accounts. If we are to detect breaches on a timely basis, we must increase and improve transparency and accountability.
It will include isolating e-mail and browsing from mission critical and other sensitive systems and data. The intelligence is clear that many, not to say most, compromises begin by duping the users of these two applications.
It will include end-to-end end, end-point to application, not perimeter, not operating system, encryption. We cannot continue to operate large enterprise networks as flat spaces, as spaces in which any system may address any other system in the network.
It will include restrictive, i.e., "white list only," granular access control close to the applications and data. It will probably include access control at every layer, e.g. between the application and the database, between the database and the file system.
These measures are neither expensive nor disruptive. Google has demonstrated that even strong authentication can be flexible and convenient. They can be implemented in parallel. There are vendors recommending them and with products and services to implement them.
This is an "off-the-top of my head" list; I am sure I have omitted something important. However, it is informed by fifty years of thinking about this problem. I am sure that many of my colleagues have measures not on my list but which they would include in a leapfrog strategy.