1. Or…
How industry standard network security
models can help achieve better network
security without introducing unneeded
complexity in your environment
2.
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
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 …
15.
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!”
Editor's Notes
Networks were introduced to get cost savings from shared resourcesIntroduction of Network ServerInternal business applications (eMail, Calendaring/etc)
What does this do for you? Keep real data tucked away deep in the networkDMZ hosts can be sacrificedStatic content didn’t require DMZ hosts to connect in to the network
Analogy of house built room by room as the family growsNow always sufficient to the task
Analogy of house built room by room as the family growsNow always sufficient to the task
Analogy of house built room by room as the family growsNow always sufficient to the task
Things like making security zones truly separate… (Not only network controls, but ensuring there are no implied application (AD) trusts)If we harden the networks without hardening the applications and systems, we don’t achieve the objective
These are only a few examples…
Nothing new. Fairly standard industry model. Requires adaptation