Document Sample
Slides Powered By Docstoc
					Network Security

Security Assurance

  The degree of confidence one has
   that the managerial, technical,
   and operational security controls
   work as intended to protect the
   IT system and the information it
   processes, stores and transmits.

When we need to test:

  During integration to validate design

  Device deployment (I.e. router or

  Prior to Certification and Accreditation

  Whenever major changes have been
   made to any part of the system

What we need to test:

 Security elements to test

  Technical Controls – Do security requirements
   function correctly?

  Performance – How well does the system perform
   under stress? Can it be easily disabled by a DoS?

  Operational – User and maintenance manuals are
   accurate and complete.

  Policy – Have all elements of the security policy,
   firewall policy, security plan, contingency plan, etc.,
   been implemented? Are the plans consistent with
   each other?

Security Requirements
  Identifying Security Requirements

  Tracking Security Requirements

  Developing the Security Test Plan

  Executing the Tests

  Documenting the Results

Identifying Security
  Collect, analyze and document the system security


           Risk Assessment

         Government Requirements (OMB A-130, NIST
          SP 800-18, SP 800-26)

         Agency Requirements (I.e. DOJ 2640)

         Watch for “hidden”, or “implied” requirements
          (i.e. – “must be compliant with all applicable
          government security requirements” can
          encompass hundreds of requirements.

Identifying Security

  Develop baseline functional
      Identify testable requirements
       and criteria for satisfying each

Tracking Security
  Build and maintain requirements tracking
   documentation (RTM). Include:
      Requirement ID Number

      Requirement Description

      Requirement Source

      Example: RTM.XLS – Security Tab

Develop Security Test Plan

    Can use RTM as basis, adding information such as:
      Test Scenarios – Statement of how the test will validate the

      Links to Test Scripts – Scripts are detailed instructions walking the
       tester through testing the requirement, including expected results.
       Generally, all Tests will have a script associated with them.

      Type of test: will vary depending on agency/company. Most
       government agencies use 4 test types: I=Inspection or Interview,
       D=Documentation, T=Test, O=Observation

      Date/Time of test

      Tester information

      Pass/Fail

    Test Plans can vary depending on their purpose

    Examples: System Test Plan.xls and RTM.xls and
Functional Testing

  Controls work as expected to implement security
      Access Controls have been applied, volumes are formatted
       with NTFS

      Authentication Controls

      Passwords

      Physical Access Controls

Performance Testing

  Requires stress testing of:

     Boundary Devices (firewalls, routers and
      IDS, border directories) – determine if firewalls
      have sufficient resources to continue functioning when

     Server CPU and RAM
        Email Servers

        Virus Checkers

        Web Servers

        Database Server

Router Security Testing

  First line of defense when protecting against
   malicious network attack

  Provide many services that can have severe
   security implications if improperly
     Default services and passwords

  Security testing provides a means of
   verifying that security functions are
   compatible with system operations and that
   they are configured in a secure manner.

Router test types:

  Functional Tests
      Access lists – ensure that necessary traffic is permitted and
       unwanted traffic id denied

      Ensure that service dependencies are functioning (I.e. Telent
       requires DNS to be accessible)

  Performance Tests
      Provides assessment of router’s robustness under the stress of
       an attack

      Should not be performed against an operational router without
       having a recovery plan in place

Router Test Scenarios

    Physical access to router

    Remote (network) access must be limited using
     authenticated logins or, if possible remote logins should be
       Telnet to router – router should either refuse the requires or prompt for
        a password

    Ability to defend against attacks:
       DoS attacks: TCP SYN Flood, Smurf, Tin00, Tribal Flood Network
        (TFN2K) – can retrieve exploits from

       IP Spoofing – Access lists should check that no packets arriving from
        outside the network contain a source address of the internal network,
        or contain source addresses of all 0’s or 1s -

Router Testing Tools:

    Nmap – scan for open TCP and UDP ports on a router

    Network monitors (packet sniffers)

    Stress testing (load generating) tools such as Hammerhead
     or hacker exploits to gauge effectiveness against DoS

    CyberCop Scanner from Network Associates

    Internet Scanner from ISS

    Security Administrator’s Integrated Network Tool (SAINT)

    Security Administrator Tool for Analyzing Networks

    Cisco’s Router Audit Tool (RAT) –
Web Server – IIS 5

  NSA Guidelines:
     IIS Logging enabled and configured

     Disable directory browsing

        Disable all non-required services: FTP, Messenger, RunAs
        Service, Task Scheduler, etc.

     Delete/move all sample directories and scripts that execute
      the samples

     FTP: Ensure Allow authors to upload executable is disabled.

     Implement auditing on operating system directories and files

Email Server

  NIST Guidelines on Electronic Mail Security:
      Do not allow remote administration from the Internet through
       the firewall

      Default accounts or passwords have been changed

      Logging recommendations implemented (log logons –
       successful and failed, security problems (spamming),
       malformed addresses, etc.)

  Tools: Microsoft’s Mail Storm, System Monitor

Servers/File Systems

  Examples (how would you test these?):
      All volumes must use NTFS

      Unused services and programs have been removed (I.e.
       arp.exe, ipconfig.exe, etc).

      Recycle bin configured to prevent deleted files from being

      System page file set to clear at system shut down

      Restrict anonymous access to NULL session connections

      Disable removable media based boot option

      Servers fail when audit logs fill


  NSA:
     Least privilege principle applied – grant permissions to those
      users that need to have access and then allow those users
      only the access levels they absolutely require (I.e. don’t give a
      group of users Full Control access to a folder if all they need is

  DOJ 2640:
     Users limited to single concurrent logon

     Dual authentication required for system administrators to

File Auditing

  NSA:
      Auditors group be created and given Full Control permissions
       to that log

  DOJ 2640:
      Auditors must not have modify permissions to the audit logs
       they are auditing!

  These two conflict – remember that NSA guidelines
   are “best practices”. The DOJ 2640 is the “gospel” to
   DOJ agencies and must be followed.

Physical Security

  Keep servers in a locked room

  Walls must be floor to ceiling (no false ceilings)

  Access Controls to system (Access Control Policy in

  Environmental controls in place (I.e. UPS, Dry-pipe
   extinguishers, Air Conditioning)


  Test that Security Plan provides controls meeting
   risks identified in Security Policy or Risk Assessment

  Test that all documentation and procedures are
   complete and accurate

  Test that all required policy documents/plans have
   been completed AND TESTED:
      Incident Response Plan

      Contingency Plan

      Key Compromise Plan

Executing the Tests

    Testers should be independent from those who engineered
     the system

    Testers will be provided the test procedures (often called a
     Test Execution Master Plan, or TEMP).

    Testers walk through the scripts and will validate whether
     or not the expected result was obtained (Pass/Fail). Testers
     are not responsible for fixing the problem.

    Testers will review the documentation to ensure that a
     procedure is complete, or may ask an operator to
     demonstrate a procedure while they “Observe”. They may
     also interview employees about policy enforcement.

    Tests that fail are re-engineered and re-tested.

Documenting the Results

  A test report is prepared by the
   tester, providing a list of those
   tests that were performed and
   their results.