Docstoc

Slides

Document Sample
Slides Powered By Docstoc
					Network Security
    Testing

 Requirements
    Testing
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.




                                       2
When we need to test:

  During integration to validate design

  Device deployment (I.e. router or
   firewall)

  Prior to Certification and Accreditation
   (C&A)

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

                                              3
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?

                                                             4
Security Requirements
Testing
  Identifying Security Requirements

  Tracking Security Requirements

  Developing the Security Test Plan

  Executing the Tests

  Documenting the Results



                                       5
Identifying Security
Requirements
  Collect, analyze and document the system security
   requirements:

        Sources:

           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.

                                                           6
Identifying Security
Requirements

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




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

      Requirement Description

      Requirement Source



      Example: RTM.XLS – Security Tab




                                              8
Develop Security Test Plan

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

      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
     TEST1.XLS
                                                                               9
Functional Testing

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

      Authentication Controls

      Passwords

      Physical Access Controls




                                                                  10
Performance Testing

  Requires stress testing of:

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

     Server CPU and RAM
        Email Servers

        Virus Checkers

        Web Servers

        Database Server


                                                               11
Router Security Testing

  First line of defense when protecting against
   malicious network attack

  Provide many services that can have severe
   security implications if improperly
   configured
     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.

                                                   12
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




                                                                        13
Router Test Scenarios

    Physical access to router

    Remote (network) access must be limited using
     authenticated logins or, if possible remote logins should be
     disabled
       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
        http://packetstormsecurity.nl/exploits/DoS

       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 -
        http://packetstormsecurity.nl/spoof/



                                                                                    14
Router Testing Tools:

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

    Network monitors (packet sniffers)

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

    CyberCop Scanner from Network Associates

    Internet Scanner from ISS

    Security Administrator’s Integrated Network Tool (SAINT)

    Security Administrator Tool for Analyzing Networks
     (SATAN)

    Cisco’s Router Audit Tool (RAT) – www.cisesecurity.org
                                                                 15
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




                                                                     16
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




                                                                      17
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
       saved

      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




                                                                    18
Roles/Accounts

  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
      Read).

  DOJ 2640:
     Users limited to single concurrent logon

     Dual authentication required for system administrators to
      servers




                                                                           19
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.




                                                                      20
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
   place)

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




                                                         21
Operational

  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




                                                            22
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.


                                                                    23
Documenting the Results

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




                                       24

				
DOCUMENT INFO