(imported comment written by SystemAdmin)
Ben,
The best way may be to build a framework that allows for one or more options rather than a one-size-fits-all approach. Consider popular security products and standards in their approach to options.
Lets use the IP security standard as an example. A standards-based approach is adopted by the IT industry. It is optional to even apply the standard. Many mainstream vendors provide out-of-the-box support for the IP security standard. When one chooses to implement IP security, there are many choices that range from weak to DOD strength configurations. The needs of the organization drive the decisions of whether to even implement the standard. If they do, they chose the strength and complexity wanted/needed to secure their particular business.
So applying that to Bigfix, I’d like to see agent authentication be optional and standards-based. Assuming a customer would chose agent authentication, there should be several levels and combinations of options. This would facilitate the range of customer needs anywhere from keeping out the casually curious to industrial strength bullet-proof security.
Those options, at a conceptual level, should address the following:
- Data-independent: Protection could be applied either selectively, by group, site, and/or by relevance clause to:
a) Fixlets
b) Tasks
c) Analysis
d) Baselines
e) Actions
f) Report/Post data
- Location-independent: It shouldn’t matter where the data is at. There should be options to apply it based on location:
a) At rest within the SQL database (encryption options)
b) At rest on the Root server, relay, or agent (encryption options)
c) In transit over the wire (TLS, SSL, etc.)
-
Standards-based: Open standards that are well tested, peer reviewd, and respected.
-
Interoperable with other major security products and protocols
So lets drill down a level and discuss the mechanisms available to achieve these options.
- Cryptography plays a huge role here. Bigfix obviously already has a PKI embedded in it. Lets expand on this inherent strength:
a) Use the builtin PKI to control not only the creation and execution of fixlet content, but who (at the console level) can view but not execute (auditor or managment) or execute but not view (delegate responsibilities to lower levels such as help desk without revealing sensitive configurations). At the relay level, optionally encrypt the action script and/or attachments of fixlets in addition to the post/upload encyption currently supported. At an agent level, not only verify the action signature, but also optionally decrypt the action script and/or attachment using either native Bigfix PKI or another specified PKI.
b) Refine delegation controls allowing more granularity.
c) Continue to sign custom content by default, but also offer various levels of encryption of the action script and/or attachments. (Similar to RMS/IRM where the content creator can choose the degree, if any, of protection.)
d) Support enabling trust via either public or private certificate authorities. Microsoft Enterprise Certification Authority integration or interoperability would be useful.
e) Consider “Health” certificate support. Many times Bigfix is used to remediate machines for NAC/NAP/etc. to bring them into compliance. What about expanding on that concept to allow the receipt and qualification of health certificates in additional to remediating agents into a healthy state? In this scenario, any agent, healthy or not could evaluate and run AV, firewall, and security patch sites, but not necessarily other custom sites content. Evaluation and execution of custom site content could be optionally predicated on one or more current health certificates either issued by Bigfix for passing remediation preconditions, but also common ones from Symantec, McAfee, Microsoft SCCM, Cisco, and others. It would be a tiered model such that “premium” content or actions would have higher requirements from the agent.
f) If there is a current user, provide an easy way to qualify user certificates and/or tokens.
- Active Directory / LDAP Directory: Directory support could provide an alternate means of authentication. They probably should not be the primary means that an agent would rely upon, but would work well to provide a second or third means of verification.
a) Computer account: A valid computer account in AD could be a way to authenticate.
b) Users and Groups: Obviously these provide many possiblities.
c) Certificate validation (OCSP) in conjunction with AD user, group, and/or computer verification is a powerful combination.
-
Radius Server support
-
Custom Relevance Expression: A custom expression could tie together a number of unique aspects for a given organization.
The question you pose, Ben, “Do you mind if the key is widely distributed?” is a challenging one. How does one establish trust when distributing the security key effectively leaves the “key-under-the-doormat”? This is a struggle with many vendors - even security vendors - who have a “secure” agent or communications. Many times it is simply security-by-obscurity.
While I have yet to see a perfect solution, there are definitely some approaches better than others. Offering multiple and diverse options allows customers to optionally apply as few or many options as their business demands. The key is multiple factors. It may not be too difficult to obtain a single factor, but to assemble all the right pieces out of a permutation of options, algorithmns, and strengths becomes a virtually impossible undertaking. For example, if someone knew that everything was protected by a single Bigfix key or certificate on the agent, they could focus on finding or cracking that one key or cert. If they knew that everything was protected by a custom list of attributes uniquely selected by each customer that may include such diverse criteria as health certificate status, computer membership in AD, a current Kerberos group membership LDAP token, etc. in addition to the Bigfix certificate, the bad guys give up since they are facing an impossible number of permutations.
Rather than Bigfix taking a shot in the dark with their one best guess at how customers want to secure their environments, provide a flexible framework into which none, one, or multiple options can be selected by the customer.