More on Deployment Model
As has been hinted during the foregoing discussion, security software does not stand alone, by itself, with no support beyond the endpoint. The days of entirely encapsulated and enclosed endpoint antivirus or anti-malware software have been gone for some time. The most pressing reason that one doesn’t simply go to the store, purchase the update, and then come home and install it is that malicious programs mutate and change too much and too often. The rate of change of malicious program types and variations has aggressively increased to the point at which it takes security companies major effort—large analysis systems and teams, as well as hundreds, if not thousands, of samples per day—in order to keep pace.
The upshot of the current situation is that an antivirus program needs updates on a continuing and repeated basis. Sometimes, these updates come more than one per day. The installation of the update has to be seamless such that the user is not inconvenienced. Imagine if every day on your working computer, laptop, tablet, what have you, you had to stop what you were doing two or three times a day to install new security software. That wouldn’t be a very good user experience. As of the writing of this work, security software makers have solved this problem by allowing the software to update itself whenever necessary.
The automatic update model, however, poses some significant challenges. How does the endpoint software establish the trustworthiness and veracity of the server that’s pushing the update? In fact, when an update event gets posted, how can the software know that this isn’t coming from a malicious source?
To make matters more complex, the validity of the update must be established such that it hasn’t been tampered with between manufacturer and download at the endpoint (integrity). In fact, most security vendors don’t want the threat agents to have the details of what’s been prevented nor the details of how protections work. At the least, these proprietary secrets are best kept such that uncovering them requires a significant work factor. Defense is better if the attacker doesn’t have the precise details of the strategy and tactics. The foregoing general requirement suggests that communications should be confidential. This is particularly true when the communications must cross untrusted networks. If updates are coming from servers across the public Internet, then the network would not only be untrusted but also hostile.
In Figure 9.2, the management console for the security software is shown as an “unknown” network. That’s because the deployers may place the management function wherever is convenient for them. Perhaps management traffic only crosses the local network. But perhaps it crosses the Internet. That decision is up to the owner of the software. In this case, let’s assume that the management console is deployed upon an organization’s local network. And, for the moment, let’s assume that computers are managed on that same network.
This is only one deployment model. Generally, for consumer-oriented security software, the management console would be a globally available cloud service. We will take up cloud management problems in the next architecture. For this architecture, the management console can be considered to exist on an organization’s internal network.
With this assumption, we can examine how a customer premise deployment model influences security decisions that are made about a system.
A working concept, when considering the security of customer premise equipment, is to understand that different customers require different security postures. Systems intended for deployment across a range of security postures and approaches will do best by placing security decisions into the hands of the deployers. Indeed, no matter the guidance from the vendor for a particular piece of software, customers will do what is convenient for their situation. For instance, regardless of what guidance is given to customers about keeping the management console for our endpoint system off of untrusted networks, customers will do as they wish. And, having exposed the management console to greater danger, the customer may very well come back and request hardening documentation in order to reduce the exposure. Numerous times, I have seen deployment teams insist that a sensitive management console must be placed so that it’s accessible from the Internet. This is generally considered poor security practice. But that statement is meaningless in the face of significant business pressure to do things in some locally unique and idiosyncratic manner.
In a situation in which the software designers also control the infrastructure and have fairly complete knowledge of the management and security practices (as we’ve seen in earlier examples), a lot of assumptions can be made. For instance, if the system is intended to be deployed to a highly restricted network, then there may be no need to build in extra security controls, such as encrypted tunnels, from the user to the management software. Such features become “nice to have.”
Conversely, where one cannot make any assumptions about where the software will be deployed and what the needs of the customer will be, the security features should include a set of protections that can be taken as a whole, or control by control, as required by the deployers. Perhaps at one organization all management consoles are placed on a somewhat open network? In a situation where the network is not providing access control, the software will need to implement authentication and authorization capabilities so that only intended personnel have access. The implementing team ought to be able to configure the system to encrypt communications over their open network. For this example security system, the communications to the endpoint software might include policy and other configuration changes. The sensitive configuration changes proceed across the network from the management console. Hence, deployers may wish to encrypt these sensitive communications. Like the ability to encrypt console to endpoint communications, each security capability needs to be under the control of the administrators managing the system. Each security feature should be individually adjustable for the needs of the deploying organization.
As much as possible, the software should place its security features and configuration in the hands of the deployers. The software maker cannot possibly determine the best settings for every deployment and every organization. Rather, the appropriate approach is to place configuration of the security posture in the hands of the customers, who can then make the best decisions for their instance. In this way, systems intended for a range of independent and locally unique deployments (“customer premise”) requires an approach that enables the security needs of those who will deploy the system to be met, not those who make it.
Returning to Figure 9.2, the management console in this case is intended to be customer premise equipment. In order to be successful, it will require protection for all communications, both inbound and outbound. Since the management console itself presents an attack surface, as we have seen in previous examples containing management interfaces for various systems, both authentication and authorization must be integral for those organizations that have no standard systems. But for those organizations that do have authentication and authorization infrastructures, the system must also be able to consume these as appropriate. [Lightweight Directory Access Protocol (LDAP) is the most widely supported authentication and group membership protocol.]
Implementing authentication and authorization systems is a nontrivial task. The design must account for the protection of stored credentials, their “password strength,” and a host of other details. We will not take these details up here, since there are any number of works that thoroughly cover this subject.
The endpoint security software must be able to validate communications from the management console. There must also be a mechanism to ensure that policy, configuration, and update communications flowing from the management console to the endpoints has not been tampered with or interfered with, en route.
Since the management console and the endpoint software don’t run on the same operating system instance (i.e., machine), a vendor binary digital signature that’s been generated across the binary at creation doesn’t authenticate this particular management instance. There is no way for the signature and hash to be sent in such a manner as to prove that the signature belongs on this one management console. While a vendor’s signature can prove the validity of the vendor’s binary, it cannot prove the validity of this particular management instance. Without an instance credential, an attacker might set up a rogue management console that pushes the attacker’s security policy to all the endpoints under management.
In this case, we need an authenticator that can be transmitted across the network and which has been generated for this instance. There are several ways to accomplish this. The way not to do it is to hardcode a credential in the binary of the endpoint and the binary for the management console as a shared secret. Statically shared secrets, a single shared secret for all instances, is one of the biggest mistakes that is made when designing systems. Such a secret should be considered compromised as soon as there are more than a few instances of the software that are beyond the control of the vendor. Such secrets are fairly easily ferreted out. They get posted to security-related websites and lists, as well as to attacker sites. When thousands of copies of the software are in use in the field, the secret is not a secret anymore. Furthermore, anyone possessing the secret now has control over every instance of the software that uses that secret. Not very secret.
The important thing is to force whatever credential will be used to be generated at installation and to a particular management context, such as an organization, a group, a department, a network, whatever works for the way that the deployers divide up the management of the software.
The details of particular types of credentials are beyond the scope of this work. X509 certificates could be generated, used, and validated. In this case, the private key used to sign the certificate will need protection. A password generated for only this purpose will work. It then must be protected wherever it is stored. There are a number of ways to achieve the desired result. Numerous and frequent discussions take place among security practitioners about the merits of one approach versus another. I believe that, for this purpose, we can state that the endpoint communicator must authenticate the management console before allowing any communications to proceed. The credential will have to be protected in storage and during transmission (i.e., either encrypted during transmission or some other scheme, such as using a public/private key pair).
The obvious solution to communications integrity is to bring up an encryption tunnel to protect the communications across networks. Typically, this is done with Transport Layer Security (TLS). Again, there’s more than one way to do this successfully. The details are beyond the scope of this work. Still, an appropriate security architecture for the management console to endpoint communications must include this requirement.
Before deploying new software, whether the updates are to the running modules or to the malware identification mechanisms used by the engine, the validity of the updates must be established. However updates are obtained for dispersal by the management console, whether by download from the software maker’s website, or through some sort of push outwards to the management console, attackers attempting to insert malicious code must be prevented. This validation could be done with a standard binary hash and signature. The hash value can be checked for validity. The signature will be made with the private key that can be checked against the public key for validity. This is the standard approach for this problem.
For most organizations, any system having to do with the organization’s security will be considered sensitive and critical. As such, the parts of the security system implementing management of the system are typically considered need-to-know, restricted systems and interfaces. In particular, any system, such as this management console, that can change the security posture of other systems requires significant protection. We explored this topic at some length and depth when examining several of the previous architectures. All of the same reasoning and the same security requirements apply, once again, to this management console. If you have any questions about what those requirements are, please feel free to read those sections once again. Like all critical and sensitive management systems, this management console will also need to be well managed, with careful consideration of access controls to the operating system and storage areas.