This document discusses the need for adopting an industry standard network security architecture model to improve security without unnecessary complexity. It outlines the evolution of typical network architectures from closed to increasingly open and exposed. This has introduced new threats that cannot be addressed by isolated security solutions alone. The document advocates aligning security controls according to well-defined architectural principles and business needs, and properly managing the integrated system as a whole.

1. Or…
How industry standard network security
models can help achieve better network
security without introducing unneeded
complexity in your environment

3.  History of a network…
• From initial state to current state
 Threats to current state
 We still have problems
 Why do architecture?
 What does it look like?

4.  Networks were closed
 No Internet connection
 Risk – relatively low
PC
Server
Laptop

5.  Let’sget an Internet connection
 Mostly outbound connections
 eMail/Web browsing Internet
PC
Server
Laptop

6.  Let’s
do business on the web
 Web server
Internet
• Mostly static content
 E-Business
Web Server
PC
Server
Laptop

7.  Multi-tieredapplications
 Sensitive data exposed through Internet
facing applications Internet
Database Web Server
Server
PC
Server
Laptop

8.  Networks are open
 Arguably mature set of standards
 Web sites integral part of business
 Security controls developed as we moved
from Closed to Open architectures
 Linear development of security controls is
not sufficient

9.  Because we have exposed resources and
data to Internet customers multiple attack
vectors exist
 Proven vulnerabilities in web servers
 Can be used as launching point for further
attacks
• Pivoting

10.  Wehave used individual technological
components to address specific needs
• PCI problems solved by a WAF?
 Throw some firewalls at it
 Let’s try an IDS/IPS
 Segmentation (PCI)

11.  Security tends to be reactive
 No structure for security controls
• (or undocumented security
assumptions/requirements)
 Every system has a unique set of controls
 Hard to manage
• Is the control managed properly?
• What are the governing rules for the management
of the controls?
• Are we in compliance with all of the controls?

12.  We can’t just throw technology at these
problems without proper process and
staffing to manage the technology
 We can’t throw security point solutions at
the problems without considering how they
work together and how they impact the
production system

13.  AlignIT Security Architecture with other
architectural domains
• Must align systems security with network and
application security
 Align
IT Security Architecture with the
business requirements
• Are we trying to solve a problem that the business
doesn’t need?
• Security Architecture needs to align with the
business risk appetite

14.  Ensure technical controls function as an
integrated system
• IDS and vulnerability management integration
reduces false positives
• Is there alignment between what our tools are
telling us
• SEIM?
 Not so sure without good brains behind it(people)
 BIG PICTURE THINKING
• One candidate …

16. Principles
General principles - These principles are the default unless a more specific rule is indicated below
Traffic traversing any security zone boundary must traverse an IA control (firewall/proxy/etc).
Any traffic traversing any security zone boundary should only allow the ports and protocols necessary for the operations of the particular application.
Any traffic traversing any security zone boundary should have source and destination IP address restrictions as narrow in scope as possible to support the operations of
the particular application.
Exceptions shall be approved by the business and IT. Approval process to be defined.
Traffic from a zone with a higher security rating to a zone with a lower security rating shall be allowed.
Traffic from a zone with a lower security rating to a zone with a higher security rating shall be denied.
Any server providing a public service to clients in the untrusted zone should not be allowed to directly connect back to the untrusted zone.
Traffic within specific zones should be as segmented as much as possible to provide separation between applications.
Application level security such as Active Directory trust levels should be closely aligned to the network architecture.
- No trust levels should be implied because network traffic is either allowed or denied
Specific principles
Traffic from the untrusted zone(0) to the trusted or restricted zone(100) shall be specifically denied.
Traffic from the untrusted zone (0) to the public facing DMZ zone (1-49) shall be allowed.
Traffic from the DMZ zone (1-99) to the trusted zone will be allowed after a thorough analysis of the risk and approval by the business and IT.
Traffic from the DMZ zone (1-99) to the restricted zone will be specifically denied.
Traffic from servers in the trusted zone(100) to the untrusted zone(0) shall be specifically denied.
Traffic from clients in the trusted zone(100) to the untrusted zone(0) shall be allowed.

17.  Document what you have (AS IS)
• Capture rationale, history, narrative behind why
things are
 Develop the target architecture (TO BE)
• Document guiding principles
 Develop plans to move from AS IS to TO
BE
• This is a LONG process… Months and years, not
weeks.
 Preach the process!

18.  Piecemeal,
ad hoc security control
development insufficient
• Architecturally
• Operationally
 Pick an architecture that fits and do it
 Operate your security discipline according
to the architecture
 “Manage the hell out of it!”