Protect IT infrastructure Part I:


IT Infrastructure

Companies must protect IT infrastructure, including cloud services, internally maintained servers and related equipment, computers, and other internal and external networking resources. From a security point of view, IT infrastructure used to be like a medieval castle with a wall around it and one big gate for entry and exit. The gate controlled traffic in and out, so the soldiers had a single choke point to monitor and control access to the castle. It was pretty safe from intruders.

Today, in a multi vendor environment where workers access data remotely and through the cloud, that solid wall around the castle now has a hundred doors in it that all grant twenty-four-hour access. With so many access points, it becomes impossible to make the fortress impenetrable.

Customers might have many ICT vendors, who usually maintain their services, as well as cloud services. Everything’s in one big mesh network like a spider web where all nodes can be connected to others. Employees are also using third-party services semi-professionally or just personally, and those aren’t controlled by the company in any way. As a result, the old fortress model has been breaking down for years. This is the IT infrastructure world we’re now living in. It’s a whole kingdom to control and secure, but there’s no solid perimeter wall.

Think Like the Attacker

We can barely scrape the surface of how attackers think in this article since our topic is mostly about how to be a successful cybersecurity manager, and we talk a bit about how to work as a defender. But understanding the enemy is paramount to success. The cybersecurity manager needs to hold in mind a few key facts about attackers and their mindset. They tend to think and feel quite differently from how IT people feel. Let’s compare.

IT cares about people and the company. They want to make information available and its usage easy—attackers want to steal it, destroy it, or make money off of it. IT wants to deploy new services and tools fast and easily, build new things, and in the process, they make the company more visible to the internet and attackers. Attackers take advantage of anything visible from the company and use it against them. They have no intent to make things work, only to make the technology and people work the way it was never intended to work for their own benefit. IT needs to be successful in defending every day, in every single service, and with every single person using the services. Attackers only need to succeed once to penetrate the defence. Evidently, the mindsets are opposite to each other.

The cybersecurity manager has to understand how to think like the adversary and wage his defence battle against the attacker’s mind, not just the technology that the attacker is using. When doing so, the cybersecurity manager will need support from professional penetration testers, also known as white-hat hackers who help to bring in the attacker’s perspective to the game and help the company to test their defences. One bit of advice, though—pay attention to the professional ethics of whom you employ to do your security testing. Crooks can’t be trusted.

When planning your penetration tests, consider the coverage of the testing you’ve done. Have you covered single points in your infrastructure, like web applications, or did you cover it all, performing a full-fledged red team exercise that inspects your whole infrastructure and tests all your defences in depth like real attackers would? Perhaps there are gaps in your understanding that need to be covered by further testing.

Mind the Colour of the Hat

White hat: Someone working with permission from their customers, using hacker techniques to test applications, networks and systems. These people are often penetration testers working for the company or its security service provider. White hats act ethically when performing tests and reveal their findings only to the customer.

Black hat: People who don’t care, they skip ethical considerations of hacking. They might hack or test your systems without permission and reveal your vulnerabilities to the public for personal gain, fame, money or other reasons.

Grey hat: Somewhere in between. Usually, grey hats are people doing things that aren’t necessarily ethical. They might do things that are considered controversial, even sometimes evil, but they tend to remain within the limit of the law. Quite often, there aren’t laws governing them, so they do it because they can. Grey hats definitely violate ethical standards at times and cause some heated debates by doing so.

The Kill Chain Model

The term kill chain originates from the military and relates to the structure of a cyberattack. Defenders can use this model to break the attacker’s chain of actions during the cyberattack. The model isn’t perfect, but it can be useful when the cybersecurity manager tries to assess whether his company has overlooked different stages of attacks and related countermeasures. There are many variations of the kill chain model. Our simplified model is presented below.

The Kill Chain Model

Defending the IT infrastructure against a cyberattack is best done early in the chain. Select defences in your IT that identify and block attacks at each stage of the kill chain to improve your chances to be successful in your defence. When you’ve figured out which technologies, processes, and services are a good fit for your defence, that will be the defence plan. We call it Cybersecurity Architecture.

IT and Security Architectures

When we refer to IT infrastructure in this article, we’re talking about creating a set of written diagrams or blueprints of how IT infrastructure is built. It’s like an architectural diagram, and quite often, it’s a bunch of technical diagrams due to the sheer complexity of systems. In fact, the goal of the IT infrastructure document is to explain in simple and understandable terms how IT serves the business, what services it uses to do that, and how they are interconnected to each other. It should show what the company itself is hosting, what’s in the cloud, and what resides with external third parties.

A useful blueprint will also contain some sort of depiction of data flowing back and forth—at least for the most important parts of IT. It will show where CRM data is stored, how it is accessed, and how it is communicated through the network, servers, firewalls, and so on. It should depict business process data flow. In a bigger company, this infrastructure document might be quite complex. But without this understanding, it’s difficult to explain to anyone how IT works.

Infrastructure can be explained and depicted from different angles, as well. One picture or diagram might represent the network layout, a second diagram might focus on the server layout, and a third might depict the data flow. There’s no one correct way to describe IT infrastructure because it’s a multifaceted entity.

IT infrastructure is a huge topic, and protecting it will require more than this article can cover. A Cybersecurity Architecture blueprint is a similarly written set of diagrams (and related documentation) that explains how the company defends itself against cyberattacks. It’s often sort of an overlay blueprint that supplements the general IT architecture of the company. The kill chain model discussed previously can be used to elaborate on different types of threats, and applicable defensive systems can be set up to counter the threats within the IT architecture. For example, if a company is defending against phishing attacks that infect workstations, they might install an antivirus solution on their workstations, email gateways, and perform automatic Bayesian email spam filtering on their email gateway. They might even go as far as using a technology called sandboxing on their workstations to isolate the email application from other parts of the operating system to prevent exploits from working against their computers. There’s plenty of choices for defensive technologies that apply for different parts of the kill chain.

The goal of Cybersecurity Architecture is to explain in understandable terms how security technologies are implemented in the IT architecture of the company and which threats they are countering.

Subscribe To Our Newsletter

Get the latest intelligence and trends in the cyber security industry.

    Develop a Good Understanding of Your IT Architecture

    Observe it from the attacker’s perspective, and use a kill chain model to visualise how an attacker perceives your assets. Find attack techniques and tactics that haven’t been covered in your defences yet.

    It’s paramount to understand your IT architecture in order to be able to create your overlaying security architecture. Study how your company’s IT is built, work with penetration testers, perform all-encompassing red team exercises, learn about the latest attacker tactics and techniques, and synthesise your own Cybersecurity Architecture to counter them. A well-documented Cybersecurity Architecture shows that the cybersecurity manager understands his defences, knows his enemy, and knows how to win his defensive battles.

    IT Infrastructure Security Policies

    Developing an effective IT security policy must consider many different facets. In our experience, most companies need to have at least a minimal set of policies in place on the following topics:

    • Security of communications
    • Networks and firewalls
    • Workstations and servers
    • Mobile devices

    These policies might be short, and they would state in high-level management language what’s required from a cybersecurity point of view. IT security policy usually must be approved by the IT director or even top management, so get the structure of the necessary policies designed early on to get them approved on time. Think critically which policies you actually need to support the security of the business and which ones would be excessive dead paper.

    In addition to these policies that set goals and requirements, there might be a number of technical policies about settings and configurations for everything run in IT. These are often called baselines, and they contain good, known configurations for different kinds of systems that the company uses. Basically, this is a matter of standardisation. When you define what baselines should be used across your systems, you’re standardising security in all similar systems across the whole company. This is by far the best way to ensure technical security in your infrastructure—it saves time, effort, and money, and it’s been proven to be very effective.

    Companies usually need more than one policy to cover IT infrastructure. They might need to create a cybersecurity infrastructure document as well, though it should not be separate from the IT infrastructure. Some companies actually don’t have infrastructure blueprints in one comprehensive document. Instead, they break it up into a network diagram, a list of servers, a list and diagram of security controls, and other separate documents. We think that the best approach is to get to know what documentation exists and then evaluate whether the company has blind spots that need better coverage.

    Technical baselines will lay out configurations for IT services like Windows domain security, servers, workstations, or firewalls. There are a lot of external resources that can be used to help create these IT documents; the Center for Information Security (CIS) is probably the most important.

    Center for Information Security (CIS)


    Templates should be used whenever possible, and set-ups should be automated and standardised. This way, the cybersecurity manager can work with IT to control the policy in technical terms. The cybersecurity manager should create the first baseline together with IT subject matter experts, enforce it, then start versioning it. A year or so later, review and improve it, then add some checks or security features in that policy before rolling it out again. Version control tools that are commonplace in software development should be used to maintain the version control and changes of these baselines.


    Yes, that means a baseline isn’t necessarily a document! A baseline can pretty well be a script with comments too! Also consider using collaboration tools that allow shared document editing to develop the policies that are on paper. Maybe you use GitHub and collaborate in Google Docs or use something similar. This is control, not anarchy, like some people mistakenly believe in the industry!

    Change Control

    If there is one common denominator for all trouble in IT and cybersecurity mishaps, it’s uncontrolled change. Standardisation is key in IT. If there are no standards, then every machine is an individual snowflake, and the cybersecurity manager cannot implement effective security. Standardisation enhances efficiency and manageability.

    So step one is to make IT policy manageable and efficient, then introduce security features. It can’t be done the other way around, though it’s tempting to set up security features on one machine at a time while leaving the others untouched. That’s not going to work—there’s no standardised management infrastructure in place.

    IT directors may feel it’s enough for them to say yes or no to a particular control; they get a warm, fuzzy feeling of being secure when they get to approve or reject a proposal. They feel comforted by sequential checkpoints that allow them to say yes or no to everything. But this is not the same thing as controlling changes in the network. Other people—not the IT directors—should be authorised to act on and enforce the baselines as quickly and efficiently as possible. Windows administrators should be able to roll out a change in security policy without management interference or having to wait for an official yes from the director.

    Key Takeaway

    Only carry high-level policies that contain principles and requirements to be accepted by the top management. Make a clear distinction between the policy, baselines, and their implementation in the policy.

    Why should administrators be empowered this way, especially when there is a need for a very fast change? Consider what happens if there’s a critical vulnerability, and they have to act within a few hours. Network outages are common. Maybe employees are unable to connect to the network or not able to use work-related applications, like email. It might be a partial or full outage or anything in between. It might include huge chunks of the whole internet being down. There’s no way that any management process can keep up with these types of immediate needs within a short time frame. A policy should enable the work that a Windows administrator is doing within a certain time frame and that they are authorised to do.

    Assign the Power


    Network Segmentation

    Now let’s take a closer look at the solutions we recommend. Please note, some information we share in this article changes rapidly.

    Let’s start with network segmentation. This means the network is split into parts, and traffic between the segments is controlled. If someone breaches the network and there’s no segmentation in place, the hacker will be able to access everything in the flat network. But if the network is segregated into segments, with routers and firewalls, the risk is distributed into smaller parts.

    A variety of network profiles and security levels can be applied to segmentation. For example, there might be a general workstation network in one place and a production network somewhere else. There may also be an email and web server network called a demilitarised zone, or internet-connected servers networked somewhere. They’re separated from each other by firewall rules so that not everything is accessible from one network to the others. That’s great, but those rules can get complex.

    Assume the Worst


    A company that we used to work for had multiple countries in their internal networks—the United States, European countries, and Japan. Their IT director told us that they had effective network segmentation in place, with limited access between countries. He said, “These different countries cannot access each other.” So we connected to their network and tried to send simple echoes, ping packets, to the other networks. This is the simplest and first test anybody in IT would do to find out whether someone is online and connected.

    If the network segmentation is effective, or it’s behind filtering, there shouldn’t be any response to the ping. But we did get a response. So then we tested some other types of network connections, actually trying to connect to the different systems and addresses in other countries. Everything—all of the services they were running in the different countries—was actually accessible. The IT manager’s impression was not correct at all, and their network segmentation was not working as expected. The network segments were there all right, but there was no filtering of traffic between the segments.

    Of course, while segmenting networks improves security, it also prevents people from using things, and there will be users who need access. There has to be a way to do that, so there need to be rules in place. The cybersecurity manager’s job is to figure out how to allow appropriate access as securely as possible. There are multiple ways to handle this need. First, identify the people who need to access the other segments. Second, select a solution that allows these people to connect to those segments flexibly and safely.

    Direct Traffic

    Gateway Protection

    Security often begins with a firewall—protection placed at the fortress gates, so to speak. Gateway protection might be the email filter that runs antivirus care and filters away spam. It might be a proxy server that protects the browser and browsing habits so that users are shielded from malicious content when they navigate to a not-so-safe page. Anything that performs perimeter checks by monitoring and controlling security measures at the border is gateway protection.

    Gateway protection comes in many different forms, and it’s usually managed by a network operations centre or security operation centre teams within the enterprise. It requires some kind of expertise to run these things—setting up email filtering services, web content management, and proxy for the company, or an anti-spam and antivirus solution or a firewall. In fact, these controls might need a team to run them.

    The trend these days is to buy such services from a cloud. An organisation might buy an antivirus or anti-spam solution for their email, or web filtering, all from an external service provider. In the past, companies used to do it by themselves. They installed a physical device and managed it themselves. Not anymore.

    When buying these services from the cloud, companies should be aware that they’re actually routing that traffic through that external provider, so they should be mindful of which partner they buy from because all of their email and web browsing traffic will be routed through that company and their assets. The Department of Defense in the United States won’t buy these services from Kaspersky in Russia or any company in China, for example.

    For most businesses, it doesn’t make much difference what service they choose. They’d be happy just to have the service. It works, it’s global, it’s fast, and it’s efficient. It can be used from the office, from home, from anywhere—it just does its job.

    cybersecurity managers just need to be aware that hiring a service creates a possibility for that vendor to monitor whatever goes through that solution. Maybe that’s a good thing—it will allow the customer to view and monitor some aspects of the traffic, like security alerts or non-compliance. It’s a great advancement and is now easier than ever to buy.


    Partner with us

      Add additional information

      Thank you for contacting Cyber Intelligence House.
      A member of our team will get in touch with you shortly to schedule a test drive of the Cyber Exposure Platform and discuss your needs