Why security policies are today managed as 30 years ago?

Why security policies are today managed as 30 years ago?
10 Feb '14 Posted by Sergio Pozo Hidalgo

Today I will start a series of posts where I am going to explain the questions we have asked ourselves (and to our customers) to understand why security policies are today managed as has been done in the last thirty years, while other IT disciplines have developed and adopted more automated, agile and less error prone visions.

Initially, we thought that the answers to these questions may give us a lot of information on the features needed in the final product, but surprisingly, most of the questions remained unanswered if not by a “Well, we know is a mess, but we have been coping with these problems for decades”... so there is really no hope in people that things can actually change to better.

Today, we are really happy to know that the intersection of our team vision and the space left out by unanswered questions have been filled with a valuable product, as we are currently running a Private Beta Program with a highly limited number of customers. Be patient, we are going to release the product to all of you in a few months. Anyway if you want to help us improve the product and validate our vision, please do not hesitate to contact us! 

So, here goes the first unanswered question...

Question 1. Why a low level, vendor-specific, complex and error prone language is still the “best” way to develop security policies in (physical or virtual) network devices?

Think about it. With all these languages you can express nearly the same set of concepts. But these languages (and graphical user interfaces that substitute them in most modern devices) are highly tiered to how a specific vendor, or even a product line of a vendor, thinks things should be implemented. Take for example Cisco ASA, IOS and NX-OS product lines. Why even the same vendor is using different languages (in different operating systems) to do the same things? Well, the answer is because of an M&A.

For example, if you want to express a security policy like

I would like that a system with IP [...] can connect to a system with IP [...] and port [...]”

or

I would like that a user [...] of an LDAP directory can connect to a the Google Hangout application

you are faced with different languages, syntaxes and semantics. And you are still expressing the same thing!!

If you ask to customers (end users in this case) why they are still using an ancient methodology, most of them will tell you things like:

  1. I am comfortable with the vendor syntax, I have been using this vendor for years and it is reliable. Well, the hardware and OS are reliable. The language has nothing to see here
  2. I have full control of what the OS and the device are doing. Umm, this is something like saying that driving a car with manual transmission is better than the automated one. It is not better, it is simply different
  3. I have full control of the performance of the device since I can use advanced syntaxes to “compress” policies and re-compact as much as possible devices’ ACLs to improve performance. Sure? A market has been developed to help you cope with performance problems on your devices. Not to talk about security problems: through 2018, more than 95% of firewall breaches will be caused by (human built) security policy misconfigurations (Gartner)
  4. I know this is a mess, but I have been doing things this way during the last decades. I am just used to this. No comment... this is the winner answer.

Unfortunately I have never got answers like:

  1. Because it is easier
  2. Because I am more productive
  3. Because what I am doing is understandable and maintainable by myself and by others in the mid term
  4. Because it is less error prone
  5. Because it is more secure

Reminds you of something? If you show these questions and answers to an expert software engineer with more of twenty years of experience he is going to quickly recognize something familiar with them. As I do. These answers are the same ones people gave when assembler was the most used programming language (and market was forcing them to shift).

As computer software became complex, new software development methodologies and languages to support them were needed in order to get things done in an easier and more agile way, raising people productivity, improving code understandability and maintainability, and reducing software errors. These are the drivers that leverage the adoption of new methodologies and programing languages.

Think again about it: no sole developer today will go back to assembler if there isn’t a really good reason to do. No developer today needs to think in both how to solve a problem, and how to implement the solution using a particular vendor-specific and hardware-specific language. Languages have evolved to instruction set agnostic entities. Computing is evolving to a hardware-agnostic commodity. And even networks are starting to follow this vision with SDN and NFV.

Shifting from a low level language to a high level one has advantages and drawbacks. And for sure all languages and methodologies have evangelists and detractors, since no software development methodology is universally recognized as being better than others.

But over time, the advantages of newer methodologies and programming languages surpass their initial drawbacks by a wide margin. Always.

The question we made ourselves at Intelliment was: Is it really impossible to bring all the modern software development methodologies and languages benefits to security policy development? Do you really believe that having so accommodation with a particular vendor, having been forced to use third party products to audit your policies, improve device performance and to cope with compliance issues really pays off in the long term? Doesn’t this add a new layer of complexity, cost and underperformance of people involved in the management life-cycle? Hey, you are incurring every year in software costs just to help you develop security policies better, just to make you a better “programmer”. But using the same old-school languages and methodologies.

We DO really believe that a paradigm shift is needed. Intelliment brings to the table a product that can solve all the exposed problems at the same time. Today. Because today the problems are not only performance, security and compliance. The true problem coming is AGILITY. Don’t you think?