Bender

Manage your firewall rules in a better way - track and maintain your policy.


Most organizations try to manage firewall rules by involving their users in
the low-level details, use technical staff to formulate, validate and assess
firewall rules, manually determine where they should be implemented, craft the
syntax, and install them during an infrequent maintenance window.  Arcane
naming schemes are used to try and associate these low-level details with
applications, customers are tracked in spreadsheets or sharepoint.  What is
manageable chaos in small environments, quickly turns into a indecipherable
mess of device configuration, and staff lose track of why or how a rule is
used, why it is in the firewall, when or if it can be removed - and security
is rapidly eroded. Ultimately, the business cannot accomplish their goals.

The fundamental failures are (a) Policy (the high level statements) is lost in
the device rules (the low level syntax), and (b) Devices implementing the
rules are the wrong place to "store" all this information.

If the above sounds like your current experience with firewalls, you should
consider the approach here.

Instead of the typical "access-list permit" approach, instead think of
   "TheseHosts" need to communicate to "ThoseHosts" for "ThisService"

By understanding the systems involved (the "thesehosts" and "thosehosts") and
the services provided by the applications (the "thisservice"), the rest of
what is needed can be easily derived, changed, updated and validated -- all
before you even lay a hand on a firewall.

"TheseHosts" want to communicate to "ThoseHosts" for "ThisService"

Groups Of Hosts use a Service Template to gain access to Groups Of Hosts.  A
Policy group defines the current and allowable sets of rules

A simple policy might include
  Host Groups
       Group		Member	Type	Owner
       workstation	huey	user		walt
       workstation	louie	user		walt
       server		pluto	genpop	jerri
       server		goofy	genpop	jerri

  Service Template
	Name	Port	Protocol	Transport	Owner
	domain	53	tcp		dns		daffy
	domain	53	udp		dns		daffy
	time	123	udp		ntp		scrooge

  Policy Groups
  	Name		Source		Destination	Template
	basic_service	workstation	server		domain
	basic_service	workstation	server		time

The above say that "workstations can access basic_service on server".  From
this data, the basic data for various firewalls is available (see "Policy
Rendering"), and correct syntax can be easily generated.

Day to Day Policy Management:
    Manage and maintain the host groups
    Manage and maintain the service template
    Manage and maintain policy statements

    This is the basis of it all.  These group/group/template approaches allow
    management of policy at a higher level - enabling tracking of all
    relationships back to the original policy statement.

    The policy statement (the "allow TheseHosts to access ThoseHosts for
    ThatService") is managed in the policy database.

    Using the host and service templates, the policy can be "rendered" to the
    source, destination and protocols -- the set of end-to-end permissions can
    be determined - this looks a lot more like the traditional
    <source,destination,protocol> tuples that people who manage firewalls are
    used to seeing.  However, these only describe the end-to-end state, and
    don't describe all devices in the path.

    The rendered policy (or "SDP" - source/destination/protocol) rules can
    then be mapped to the network topology to determine the actual
    configuration statements that are necessary to enable the original policy
    statement.

But I also need to ...

    There is a lot of meta-data that needs tracking to understand the
    provenance (the history and control) of policy, rules and services and
    host groups.  This tends to vary widely across different organizations,
    and may include date/age of the policy or rule, who made the change, who
    the various owners are (service, server, risk), and so forth.

    The approach to resolve this is to make the system data-driven, rather
    than control driven.  WHATEVER fields you define in the databases will be
    tracked and managed.  Need to add a new field? Stop the system, and update
    the database with a new column that you need.  It will then be available
    in all matching/searching operations.

    Some recommended fields:

    	start/stop dates - this allows tracking of history of rules by never
    	 	    actually deleting data from the system.  If a rule needs
    	 	    to be "deleted", simply set the end date to the current
    	 	    date.  If a rule needs to be updated, then set the end
    	 	    date on the old record, and start a new record.  In this
    	 	    approach, policy statements can be set to "reconfirm" at
    	 	    some date, and the entire history of the policy is
    	 	    available by looking at records without regards to the
    	 	    dates.

	owners and risk party - track the owner of the server or service
    	       	   separately from the party that signs off on the risk.  This
    	       	   is the bases for the control gates in work-flows to allow
    	       	   sign-offs and cross-checking and audit functionality.

     Some required fields:

     	  To work generically, a minimum set of fields are required (though
     	  matching/searching operations can occur across all available
     	  fields).

	  Note that the required fields are _not_ enough to generate valid
	  configuration in a running network - just enough to tell different
	  things apart.  For example; the SDP database doesn't require
	  protocol (tcp or udp), but those would be necessary to generate
	  valid ACLs.

	  Required fields for databases (the column names are capitalized)-
	  * Host Groups: NAME of the group, and MEMBER of the group
	  * Service Templates: NAME of the service, and PORT that it uses,
	    	    PROTOCOL and DIRECTION
          * Policy Database: NAME, SOURCE, DESTINATION, TEMPLATE 
	  * SDP Database: GROUP, NAME, SOURCE, DESTINATION, DIRECTION
				PORT, PROTOCOL, SOURCE_IP, DESTINATION_IP
	
Does it work on a Juniper/Cisco/etc?

     Since only the data is stored and manipulated, the last steps of
     generating valid configuration involve (a) determining the topology and
     devices, (b) translating the SDP sets into configuration language.

     From a <source, destination, port, protocol> tuple, it is pretty trivial
     to generate valid configuration for IOS ACLs, IP Tables, or what have
     you.  An example "ios-genpol.py" is included as an example of reading the
     SDP tuples, and wrapping platform syntax around it.

Getting Started

 Bender is written as a python class library - but includes some example code
 at the bottom of the "bender.py" for some trivial examples.  For a more
 complete demonstration, consider the examples using Flask in either
 "bender_ui" (using CSV formatted files), or "benders_ui" (using MariaDB).
 
 Example policy-generating code is in asa-genpol[s].py, and ios-genpol[s].py.
 Once the demonstration is running, you can use these programs to generate
 configuration for the indicated platform.

;; Local Variables:
;; mode: text
;; fill-column: 78
;; End: