How do you define and manage your perimeter?

The Driver Behind This

Just like the first step of avoiding a trap is knowing of its existence; the first step in protecting against something is knowing it’s there.  Knowing the variety of ways in and out of your organization’s network environment is equally important.  Those points of entry and exit NEED TO BE MANAGED AND PROTECTED TOO. While your firewall is normally the first line of defense when employing a Defense in Depth model, it should not be your only line of defense.  You should be including not only your perimeter firewall, but also applications that allow data exchanges (including APIs), X-as-a-Service providers, Wireless Access Points, mobile devices, as well as Shadow IT (i.e., Gramarly, OneDrive, DropBox).  When networks are poorly designed and architected, they will degrade other security capabilities.   Make sure the perimeter is documented (inventoried, if you will) and that it is centrally managed.  Ensure you know what data is flowing where, how it’s being exchanged, what the classification is (e.g., public, private, secret), when it’s being shared and how it gets from point A to point B. 

One of the biggest issues we tend to run into are poorly designed networks – they were initially built and then have been left to fend for themselves.  Typically, organizations are decentralized and rely on disparate local IT staff who are incapable of delivering the quality that is required of the business.  Often, these IT departments are hamstrung by limited budgets, have significant skills gaps and are subject to having local management pressure them to bypass controls.  Having centralized management over ingress/egress tends to make or break an organizations ability to secure themselves appropriately, as you can only protect what you know about.  Additionally, centralized management of these efforts ensures staff have the proper skills required, forms a consistency in service delivery and often reduces overall operating costs, as well as reducing the chances of a major incident.

© zemkooo2

Processes, Practices, and Activities That Address This Question

Inventory every logical method in and out of your organization.  Know the data elements being shared and with whom you are sharing them.  Ensure all gateways (ALLL, not 80%, not 90% not 99% – but ALL) are accounted for – Firewall, VPN, B2B Connections using ACLs on a Routers, Interactive Applications, API calls – ALL.  Make sure that a single group with well-established practices and processes, and approved tools, manages them.  This ensures consistency!  With each of these, make sure you capture the logs in a centralized repository – ALL the logs.  This allows you to not only troubleshoot network and system issues but will be extremely valuable and handy for demonstrating conformance with any applicable compliance requirements. In addition, logs are immensely vital during an incident.

Common pitfalls:

  • “Allowing branch/satellite offices to manage their own Internet (network) connections.”
  • “Collecting, but not reviewing the logs provided by applications and instrumentation.”
  • “Not defining logging requirements in-house developed applications.”
  • “Defining standards and not auditing them (expecting the branch/satellites to self-govern).”

Continued Reading

Leave a Reply

Your email address will not be published. Required fields are marked *