Security
Security is top-of-mind, especially right here where Juniper experts share their insights on the latest security trends and breakthroughs
Juniper Employee , Juniper Employee Juniper Employee
Security
Adaptive Security Policies for Dynamic Security Environments
Dec 14, 2017

 

Dashboard.png

 

Adaptation – the art of sensing different environment conditions and taking appropriate actions to adjust to the new conditions  is at the heart of our survival as well as success. Inability to adapt, and adapt fast, to changing conditions could result in dire consequences. 

 

A simple routine we all follow is choosing appropriate dresses and accessories based on the weather conditions we foresee that day. Sunny weather? Out comes our t-shirts, caps and sunglasses. Cloudy and rainy out there? Raincoats, umbrellas and the likes are chosen. Snow expectations? Out comes our multi-layered snow jackets and other snow wear.   

  

weather.png

 

The question you need to consider is, “How easy is it for my security operations teams to adapt to different security environmental conditions?”.  Let us have a closer look on how statically defined network security policies make is challenging to adapt and how Juniper’s innovative, patent-pending construct called “Dynamic Policy Actions” allows you have right security for right conditions. 

 

Network Security policies are static  

Network security policy exposed by traditional security vendors is very static in nature. Typical policy structure looks something like: 

Rule Number 

Source Traffic Match Criteria 

Destination Traffic Match Criteria 

Firewall Action(s) 

Logging 

Action 

IPS 

.. 

.. 

.. 

.. 

.. 

.. 

1000 

Any 

MyCriticalServers 

PERMIT 

LOG 

DISABLE 

.. 

.. 

.. 

.. 

.. 

.. 

 

The logic for each rule is quite simple – for a particular “traffic match criteria”, admins can configure one set of “security actions”.  

 

Challenges  

Security operating environments are rarely static in nature. Let’s look at a scenario based on changing threat level: 

  • Policies you want to enforce when the network is running normal could be quite different from the policies you want to enforce when the network is under significant attack, or even when your network is already compromised and the security team is trying to identify and isolate compromised assets.  

Static policy model as depicted above introduces significant operational challenges adapting to these different situations. For example: 

  • When the team realizes that their network is under attack, they have to first process thousands of the rules in the rule table, one at a time, to figure out how to adapt those rules 
  • Make changes to multitude of rules and push out to the firewalls. Precious security admin cycles are spent on rule modifications instead of focusing on isolating and remediating from attacks  
  • The risk of breaking some of the mission critical services is quite high at this stage because of the high volume of unplanned changes 
  • Once the threat is isolated/mitigated, the team has to revert all the rules back to the normal profile. Of course, chances of mistakes, service outages etc exist here as well 

 

Note: Though I've give one scenario where dynamic policies are useful, there are a multitude of such possible scenarios. A new approach and thinking is needed to address these challenges. Juniper's solution I present below is quite generic in nature. It supports customers defining their own variables, conditions and map right actions based on specific custom conditions 

 

People staying in fire prone areas run through fire readiness and evacuation planning, people in earthquake prone areas go through earthquake preparedness exercises. It is high time cyber security teams go through normal as well as attack preparedness scenarios for improved security 

 

Juniper solution 

Juniper’s Security Director is introducing an innovative new capability – called, Dynamic Policy Actions – to simplify the workflow of pre-creating different security actions that the team wants to take under different environmental conditions.  

dial.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The workflow involves: 

  • Create different custom environmental variables. The values of these variables can influence different rules 
  • Use the conditional evaluators based on these variables in the network security policies 
  • Test different profiles ahead of time to make sure that the rule behavior is as planned 
  • When a change to environmental condition is identified, change the value of the variable to reflect the current situation 
  • Security Director auto-calculates the changes to the relevant rules and based on the admin approval pushes out these changes to the entire network as needed 

 

The rule table will now look something like: 

Rule Number 

Source Traffic Match Criteria 

Destination Traffic Match Criteria 

Environmental 

Condition 

Firewall Action(s) 

Other Actions 

.. 

.. 

.. 

.. 

.. 

.. 

1000 

Any 

MyCriticalServers 

ThreatLevel=GREEN 

PERMIT 

LOG 

 

 

 

ThreatLevel=ORANGE 

PERMIT 

LOG 

IPS_STD_PROFILE 

 

 

 

ThreatLevel=RED 

DENY 

LOG 

.. 

.. 

.. 

.. 

.. 

.. 

 

You would have probably noticed that the rule table now introduces a new “Environmental Condition” column. The “condition” is first evaluated to identify related set of actions the system will take. For example, if the ThreatLevel is “Orange” at a point of time, the system enables IPS service automatically for the corresponding traffic.  

 

Benefits  

The benefits of this model are all too apparent: 

  • Security teams can pre-create different security scenarios and test out the behavior of the system under different conditions 
  • Time to react to different situations drastically reduced.  
  • At the critical time when the team has to focus on identifying the attacks that the system may be under, they do not have to burn cycles of rule table manipulation. 
  • Dramatically reduced manual errors during the change workflow 
  • No requirement to hire developers to build devops oriented programs. This feature is natively delivered by the management solution 

 

One of our customers reported the process of reacting to a major attack used to take 30+ hours for a team of six Security admins before. Now, the reaction time got reduced to 3 minutes with just one admin taking care of the change 

Streamlining security operations for normal as well as other changing conditions helps reduce business risk. 

 

As with all flexible frameworks, it is impossible for me to imagine different possible ways in which you can use this solution. Feel free to comment on how you see you can deploy and use this feature in your network

 

References:

Dec 12, 2017
Juniper Employee

Great session at @NXTWORK

Dec 14, 2017
bahulh

Simplifying SecOps is really cool; excellent innovation.

Top Kudoed Members