Security Architectures Cyber Security Lab Spring 2010.

26
Security Architectures Cyber Security Lab Spring 2010

Transcript of Security Architectures Cyber Security Lab Spring 2010.

Page 1: Security Architectures Cyber Security Lab Spring 2010.

Security Architectures

Cyber Security Lab

Spring 2010

Page 2: Security Architectures Cyber Security Lab Spring 2010.

Security Policy

• A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide – RFC 2196

• Security policy separates the world into secure and insecure states

– What is the information to be protected?– Who is responsible?

• Dictating what not how• Must be feasible to implement

Page 3: Security Architectures Cyber Security Lab Spring 2010.

Security Policy

• The organizational security policy guides the requirements for a security design– The security policy is an English document– Hopefully rather precise– Defines the goals of the security implementation

• Often there is a hierarchy of policy– From broad organizational policy– To more detailed technology specific security

guidelines

Page 4: Security Architectures Cyber Security Lab Spring 2010.

4

Hierarchy of Policies

Organizational Policy

Departmental Policy

Department Standards

CSIL-Linux10SE Linux

Policy

Linux LabUmask settings

Page 5: Security Architectures Cyber Security Lab Spring 2010.

5

Natural Language Security Policies

• Targeting Humans– Written at different levels

• To inform end users• To inform lawyers• To inform technicians• Users, owners, beneficiaries (customers)

• As with all policies, should define purpose not mechanism– May have additional documents that define how policy maps to

mechanism

• Should be enduring

– Don't want to update with each change to technology

• Shows due diligence on part of the organization

Page 6: Security Architectures Cyber Security Lab Spring 2010.

Security Policy References

• RFC 2196 – Site Security Handbook– Discusses policy and more general design and

implementation issues. Published in 1997, so some of the technology references are dated, but the general recommendations are still valid

• SANS policy examples– http://www.sans.org/resources/policies/

• Information Security Policies and Procedures, Thomas Peltier– In the library

Page 7: Security Architectures Cyber Security Lab Spring 2010.

7

University of Illinois Information Security Policies

• University of Illinois Information Security Policies– System wide policy; Identifies what, not how– http://www.obfs.uillinois.edu/manual/central_p/sec1

9-5.html• CITES UIUC standards and guidelines– DNS - http://www.cites.uiuc.edu/dns/standards.html– FERPA -

http://www.cites.uiuc.edu/edtech/development_aids/ferpa/index.html

• CS Department policies– https://agora.cs.illinois.edu/display/tsg/Polici

es

Page 8: Security Architectures Cyber Security Lab Spring 2010.

What is a security architecture?

• A framework that guides the security implementation– Guided by the security policy– Breaks the problem into modular pieces

• Can implement and perfect a module • Can repeat implementation of proven modules and

organization grows, e.g. remote office module

• Abstracting from implementation specifics aids in understanding the guiding structure of the system

Page 9: Security Architectures Cyber Security Lab Spring 2010.

Architecture Abstractions

• May be useful to think in terms of physical analogs– Data in file cabinets

• Drawer granularity• Locks

– Fortresses or silos • Gates or guards at limited access points• Toll booths

Page 10: Security Architectures Cyber Security Lab Spring 2010.

Security Architectures

• Can generalize security architecture for classes of systems

• Can be found for many general system elements– J2EE applications– Client server applications– .Net applications

Page 11: Security Architectures Cyber Security Lab Spring 2010.

Cisco SAFE

• A series of network security architecture blueprints– Identifies frameworks for particular scenarios– Analyzes placement of security enforcement devices in the

network design• Even if you don’t use these modules, the analysis can help you

understand reasons for using mechanisms at various points

• Modules enable people to incorporate portions of the blueprint into their environment

• Following diagrams are from the SAFE Enterprise document

– Copies handed out in class

Page 12: Security Architectures Cyber Security Lab Spring 2010.

Cisco Icon Overview

• Complete overview at http://www.cisco.com/warp/public/503/2.html

Page 13: Security Architectures Cyber Security Lab Spring 2010.

Overall Enterprise Design

Page 14: Security Architectures Cyber Security Lab Spring 2010.

Enterprise Campus

Page 15: Security Architectures Cyber Security Lab Spring 2010.

Management Module

Page 16: Security Architectures Cyber Security Lab Spring 2010.

Building Distribution Module

Page 17: Security Architectures Cyber Security Lab Spring 2010.

Building Module

Page 18: Security Architectures Cyber Security Lab Spring 2010.

Server Module

Page 19: Security Architectures Cyber Security Lab Spring 2010.

Edge Distribution Module

Page 20: Security Architectures Cyber Security Lab Spring 2010.

Second portion of architecdture

Page 21: Security Architectures Cyber Security Lab Spring 2010.

More of the second portion

Page 22: Security Architectures Cyber Security Lab Spring 2010.

Corporate Internet Module

Page 23: Security Architectures Cyber Security Lab Spring 2010.

Corporate Internet – Another View

Page 24: Security Architectures Cyber Security Lab Spring 2010.

VPN/Remote Access Module

Page 25: Security Architectures Cyber Security Lab Spring 2010.

E-Commerce Module

Page 26: Security Architectures Cyber Security Lab Spring 2010.

E-Commerce Module, another view