[Infrastructures] Network automation: An Architects View
Ian Glossop
ian.glossop@glomal.co.uk
Mon, 23 May 2005 10:29:01 +0100
--=====================_52156781==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Apologies for cross-posting, but this list seems to be having much the same
discussion as the network-automation@greatcircle.com list, so I thought
there might be some useful cross-fertilisation to be had.
> My real problem with acls is also maintenance oriented. What I would
> really like is to take a written policy like "I want to never except
> netbios packets from the Internet", and convert that into a proper acl
> at any relevant security border point. That has historically been very
> hard.
>
> One usual approach to this seems to be to use some sort of
> meta-language to represent the policy, and to then generate the
> specific acl from that. This usually doesn't work real well, because
> the meta-language doesn't represent policy, but instead represents an
> abstraction of the underlying acl. In addition, the meta-language is
> usually as abtuse as the native acl language...which makes it just as
> hard to maintain in many cases.
>
> Perhaps an interesting approach would be to define a set of devices
> that represent borders between security zones, and then create a set of
> rules (i.e., policy) about the types of connections between the zones.
> Again, there's the problem of how to represent the policy in the
> correct acl language (which also varies considerably by platform, just
> to make it more fun.) In an ideal world, a change in the policy would
> be automatically pushed into a proper form for auto-configuration.
>
> Verification of the new config might be an interesting problem....
> (My apologies if some of this has already been hashed out here...I'm
> still trying to find the time to read the archives of this list. :)
>
> -David
Having lurked about on this list for a short while (and like David not
really having the time to keep up let alone try to catch up), I have found
the discussion quite interesting and was prompted by David's comments to
describe my personal (somewhat utopian) ideal in the hope of stimulating
yet more discussion.
As an architect what I'm looking for is a vendor-independent,
technology-independent, possibly pictorial, language with which to describe
the architecture of solutions. This includes not only network topology,
security zones, policies, boundary and core network devices (firewalls,
routers, switches and load-balancers/content switches) etc as David
suggests but also server machines, middleware (weblogic, MQ Series etc),
databases, (capacity, perfomance and health) monitoring systems,
application software instances and deployment systems. Maybe something like
Data Centre Markup Language could be the starting point for this
"Architecture Specification Markup Language" (ASML).
I then want a similar, possibly related language with which to specify the
technology selections that I make to implement the solution. Again it
should be vendor-independent and technology independent (it would have to
be by definition).
Then I want a system that can bring together the architectural description
with the technology selection and produce specific configuration
information for the devices and software involved. So if I specify a
certain network topology (and access control policies etc) and then choose
to implement using Cisco routers and switches this system would derive the
appropriate IOS configurations for each of the devices involved.
Clearly no single vendor is going to produce such a system so it would have
to be a modular approach with standardized (software) interfaces into which
vendors could plug their components to derive the configurations for their
devices (software or hosts/OS) from the vendor-neutral standard ASML.
Furthermore, I want this system to maintain records of the architectures I
specify and to provide the facility to compare a proposed new architecture
against an existing (or old) architecture and work out what the differences
are in terms of new devices/machines that have to added (or old ones that
have to be removed) and configuration changes required - on network kit,
servers, middleware, apps software etc. (and maybe even assign some costs
to those changes) - in essence doing much of the 'bureacratic' part of an
impact assessment.
Finally I want this "architecture system" to interface with automated
deployment and configuration tracking systems to deploy the derived
configurations in a clean, safe, controlled manner and periodically compare
the "in-the-field" configurations against those derived from the
architecture reference description (and of course flag up differences or
unauthorised changes).
Obviously this is Utopian at the moment but products like Opsware and
ThinkDynamic Orchestrator are moving in that direction in the server space.
Network automation ought to move in the same direction.
This is my personal "big picture" vision. Others may have different views
.... ?
<Security Policy>
<Boundary Router>
<Instance Router1>
Site=SiteA
<Interface Outbound1>
WANLink=toSiteB
</Interface>
<Interface InsideLAN1>
LANLink=toSwitchAlpha
</Interface>
<Interface InsideLAN2>
LANlink=toSwitchBeta
</Interface>
</Instance>
<ProtocolRules>
<Protocol netbios>
<Transmission>
Inbound=Disallow
Outbound=Disallow
</Transmission>
</Protocol netbios>
</ProtocolRules>
</Boundary Router>
</Security Policy>
Anybody write an awk, perl or XSLT script to translate this into a Cisco
ACL ? Or a visual representation ?
Regards,
Ian.
--=====================_52156781==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<dl>
<dd>Apologies for cross-posting, but this list seems to be having much
the same discussion as the network-automation@greatcircle.com list, so I
thought there might be some useful cross-fertilisation to be
had.<br><br>
<dd>> My real problem with acls is also maintenance oriented. What I
would
<dd>> really like is to take a written policy like "I want to
never except
<dd>> netbios packets from the Internet", and convert that into a
proper acl
<dd>> at any relevant security border point. That has historically
been very
<dd>> hard.
<dd>>
<dd>> One usual approach to this seems to be to use some sort of
<dd>> meta-language to represent the policy, and to then generate the
<dd>> specific acl from that. This usually doesn't work real well,
because
<dd>> the meta-language doesn't represent policy, but instead
represents an
<dd>> abstraction of the underlying acl. In addition, the
meta-language is
<dd>> usually as abtuse as the native acl language...which makes it
just as
<dd>> hard to maintain in many cases.
<dd>>
<dd>> Perhaps an interesting approach would be to define a set of
devices
<dd>> that represent borders between security zones, and then create a
set of
<dd>> rules (i.e., policy) about the types of connections between the
zones.
<dd>> Again, there's the problem of how to represent the policy in the
<dd>> correct acl language (which also varies considerably by
platform, just
<dd>> to make it more fun.) In an ideal world, a change in the policy
would
<dd>> be automatically pushed into a proper form for
auto-configuration.
<dd>>
<dd>> Verification of the new config might be an interesting
problem....
<dd>> (My apologies if some of this has already been hashed out
here...I'm
<dd>> still trying to find the time to read the archives of this list.
:)
<dd>>
<dd>> -David<br><br>
</dl>Having lurked about on this list for a short while (and like David
not really having the time to keep up let alone try to catch up), I have
found the discussion quite interesting and was prompted by David's
comments to describe my personal (somewhat utopian) ideal in the hope of
stimulating yet more discussion.<br><br>
As an architect what I'm looking for is a vendor-independent,
technology-independent, possibly pictorial, language with which to
describe the architecture of solutions. This includes not only network
topology, security zones, policies, boundary and core network devices
(firewalls, routers, switches and load-balancers/content switches) etc as
David suggests but also server machines, middleware (weblogic, MQ Series
etc), databases, (capacity, perfomance and health) monitoring systems,
application software instances and deployment systems. Maybe something
like Data Centre Markup Language could be the starting point for this
"Architecture Specification Markup Language" (ASML).<br><br>
I then want a similar, possibly related language with which to specify
the technology selections that I make to implement the solution. Again it
should be vendor-independent and technology independent (it would have to
be by definition).<br><br>
Then I want a system that can bring together the architectural
description with the technology selection and produce specific
configuration information for the devices and software involved. So if I
specify a certain network topology (and access control policies etc) and
then choose to implement using Cisco routers and switches this system
would derive the appropriate IOS configurations for each of the devices
involved.<br><br>
Clearly no single vendor is going to produce such a system so it would
have to be a modular approach with standardized (software) interfaces
into which vendors could plug their components to derive the
configurations for their devices (software or hosts/OS) from the
vendor-neutral standard ASML.<br><br>
Furthermore, I want this system to maintain records of the architectures
I specify and to provide the facility to compare a proposed new
architecture against an existing (or old) architecture and work out what
the differences are in terms of new devices/machines that have to added
(or old ones that have to be removed) and configuration changes required
- on network kit, servers, middleware, apps software etc. (and maybe even
assign some costs to those changes) - in essence doing much of the
'bureacratic' part of an impact assessment.<br><br>
Finally I want this "architecture system" to interface with
automated deployment and configuration tracking systems to deploy the
derived configurations in a clean, safe, controlled manner and
periodically compare the "in-the-field" configurations against
those derived from the architecture reference description (and of course
flag up differences or unauthorised changes).<br><br>
Obviously this is Utopian at the moment but products like Opsware and
ThinkDynamic Orchestrator are moving in that direction in the server
space. Network automation ought to move in the same direction.<br><br>
This is my personal "big picture" vision. Others may have
different views .... ?<br><br>
<Security Policy> <br>
<Boundary Router> <br>
<Instance Router1> <br>
Site=SiteA <br>
<Interface Outbound1> <br>
WANLink=toSiteB <br>
</Interface> <br>
<Interface InsideLAN1> <br>
LANLink=toSwitchAlpha <br>
</Interface> <br>
<Interface InsideLAN2> <br>
LANlink=toSwitchBeta <br>
</Interface> <br>
</Instance> <br>
<ProtocolRules> <br>
<Protocol netbios> <br>
<Transmission> <br>
Inbound=Disallow
<br>
Outbound=Disallow <br>
</Transmission> <br>
</Protocol netbios> <br>
</ProtocolRules> <br>
</Boundary Router> <br>
</Security Policy><br><br>
Anybody write an awk, perl or XSLT script to translate this into a Cisco
ACL ? Or a visual representation ?<br><br>
Regards, <br>
Ian.<br><br>
<br>
</html>
--=====================_52156781==_.ALT--