Assessing your Organization’s Network Perimeter (pt. 2)

Step 4:
Once you have completed step 3 you should have all the raw technology information you need to perform your assessment but prior to performing your analysis you must first cross reference all the information gathered in steps 1 through 3 with the functions and purposes you identified in Part I of “assessing your perimeter” marking the first sanity check of our exercise.

A few notes to consider when mapping devices and software to the functions and purposes:

  1. Start by mapping the end points to the functions and purposes.
  2. It is ok to map end points to multiple functions and purposes.
  3. It is ok to map a device to more than one function and purpose.
  4. It is ok to map a piece of software to more than one function and purpose.
  5. If you can not map any endpoint(s) or device(s) to a function or purpose either you are not supporting that function or purpose or you are missing an end point and devices.
  6. If you can not map any software to a function or purpose either you are not supporting that function or purpose or you are missing some software.
  7. If you can not find a purpose of function for a piece of software you are either missing a function or purpose or the function or purpose of the software is no longer required. (This is probably more common than you might think)
  8. If you can not find a purpose of function for an endpoint(s) and/or device(s) you are either missing a function or purpose or the function or purpose of the endpoint(s) and/or /devices(s) is no longer required. (This is probably more common than you might think)

At this point it is probably a good idea to review your spreadsheet with the network architect (or someone else in your organization that may be suited to assist) to make sure you are capturing the information completely, accurately and have mapped everything effectively. Please make sure you review your list of unmatched components with the architect as well as the architect may be able to fill in the blanks.

Step 5:
Once you have confirmed your information with a trusted source you can finally begin your analysis. For this step you will be required to refer to your organization’s security and operational standards. If you do not have security and operational standards then refer to Part III of this series. If you do have these standards your analysis should consist of the following:

Level I by End point

  1. Validation that each device within this endpoint is configured based on the organization’s security and operational standards.
  2. Validation that the architecture does not permit bypassing firewall to enter internal network.
  3. Validation that all applications are at the proper version levels as per organization’s security and operational standards.
  4. Validation that all applications are at the proper patch levels as per organization’s security and operational standards.
  5. Validation that all the patch levels for each device within the endpoint is up to date based on the organization’s security and operational standards.
  6. Validation that any monitoring devices are configured as per organization’s security and operational standards.
  7. Validation that all end point devices are not vulnerable to network layer penetration attack by performing network penetration test.
  8. Validation that all end point devices are not vulnerable to application layer penetration attack. by performing application penetration test.

Level II by purpose and function.

  1. Validation that the endpoint is in the proper form to support the purpose and functions it is supporting. For example if the purpose and function expects a secure point to point connection to a business partner to transfer sales information and the endpoint is an unprotected public link you have a problem.
  2. Validation that only the required ports and protocols are enabled on the devices to support each purpose and function.
  3. Firewall rules must be examined to ensure that they support the purpose and functions of the endpoint.

A few thoughts before we leave step 5:

  1. Complying with patch levels does not always mean you must have the latest patches in place. What level of patching required should be noted in your standards and if the latest patch levels are not required there should be criteria for why and how to judge if the patch levels meet the documented and agreed upon criteria.
  2. As with patches complying with version levels does not always mean you must have the latest version in place. The version level that is required should be noted in your standards and if the latest version levels are not required there should be criteria for why and how to judge if the version levels meet the documented and agreed upon criteria.
  3. External penetration testing is often performed more reliably by external third parties who perform this function often and have the facilities to execute it quickly and cost effectively. My recommendation is to choose a reliable third party and have them perform periodic penetration testing of your perimeter end points.
  4. Firewall rules must be viewed in their entirety as some rules supersede others. Prior to reviewing the firewall rules get some background on your firewall so that you can understand the full rule set when you read it.
  5. Some appliance vendors will try and tell you that they do not have an operating system but, they do even if it is proprietary there is one and it is usually based on open source UNIX operating system.

One Comment

  1. Rene w/ NCP Jun 17, 2008 at 2:44 pm | Permalink

    What should be mentioned as (one of the many) details would be that users within a company using WLAN although physically within the confines of the building are to be treated as remote access users. Someone outside on the street with a laptop and a malicious intent should be able to detect and possibly participate within the WLAN if not secured enough, as if they’re within the building and as one of the users. It’s therefore imperative to realize that physical and virtual perimeters do not necessarily coincide!

    Another point would be how far do I want to ‘extend the perimeter’ and use the right ‘technology’ to fulfill the requirements:

    Incidental access to internal resources can best be facilitated with SSL-VPN access. This allows for a limited access to internal resources by those that need it; such as suppliers/consultants/contractors and so on. This doesn’t require the user to install a ‘client’, but merely downloads the code within the browser and uses the browser to access the internal resources, and this access can be carefully controlled centrally on the SSL-VPN gateway.

    Conversely a full time employee may require to have access to the ‘regular’ resources he would normally have at his desk, while he’s on the road. An ‘full access’ or ‘LAN emulation’ (working remotely as if one is sitting at one’s desk) VPN solution would be a better suited option. This would imply that the latter’s work platform is secured; not only the communication between the two points, but the remote user’s device has become an extension to the corporate network perimeter; and thus should be protected accordingly. Why attack the corporate ‘perimeter’ firewall, when one can attack and possibly use a remote access user’s machine as a stepping stone into the corporate network?!

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*