Let’s take a moment to examine the potential of Symantec’s Data Center Security Agents on Veritas NetBackup Appliances
They once lived happily ever after…
Many of you should be familiar with the big names in information management and security. Veritas and Symantec. Once separate entities, they courted each other, merged under the same umbrella, and then due to wanting different things in life, the two companies split apart. During their time together there were some interesting synergies that are often overlooked and potentially unknown to many who own their products. Even after the split, some of these lingering elements of their partnership remain.
One of Symantec’s more interesting products that I’ve worked with is known as Data Center Security: Server Advanced, which is really just a rebranding of Critical Systems Protection (in case you were more familiar with that name). For those unfamiliar with the product, it is an agent based Host Intrusion Detection & Prevention system. There are some other core features built into it, but from the highest level, it’s an HIDS/HIPS system. Where am I going with this?
The powerhouse backup system under the Veritas brand is, NetBackup. Their 52xx series appliances are beastly hardware systems that can contain – WoW! mUch terabytes of information. Such retention.
Prior to their divorce, the brains at the Symantec \ Veritas hybrid decided it would be a smart idea if they took their really cool security agent and use it to hardened their super beastly hardware backup appliances. This is where things got interesting.
When someone purchases a NetBackup Appliances in the 52xx series range, they are also getting a license for a DCS: SA agent. Each appliance comes loaded not only with a highly customized set of detection and prevention policies, but it also has the central management console for DCS: SA available to grab from the NetBackup web console. Which means that if you have multiple NetBackup Appliances, you can centrally manage the security policies across all of them, and further tune these policies to best suit your environment. No way that’s so cool!
Time to get practical, factual, and in the weeds…
As a best-practice, information security teams should threat model risks and make sure that the appropriate controls are in place to reduce the impact of or fully mitigate those risks. If they are doing that correctly, the following questions will pop up, “What happens if a disgruntled employee attempts to delete all our backups?” “Do we have the ability to audit administrators command line input on our backup systems?” “What subnets are allowed SSH access to our backup appliances?”
Out of the box, the DCS: SA policies themselves are pretty rigid as far as the restrictions they put in place on the system. However, there is still room for customization, as there were some things that they were unable to put in due to unknown environment variables such as networks, user accounts, and other organization details. Here’s some after the box customizing that is worth considering:
-
Turn Off Policy Override
There is a default feature in the policies that allows for a maintenance override of the prevention policies so that general admin tasks can be completed. Let’s think about that disgruntled backup admin scenario. The best option to prevent this is to create two policies, one that allows for policy override and one that does not.During normal operations, no policy override is allowed. When a maintenance window is approved a security engineer can apply the policy that allows override and then revert back to the more restrictive policy at the end of the maintenance. We now have appropriate segregation of duties, the disgruntled backup admin can no longer elevate his own privileges.If the security admin is smart, they will automate this process by taking advantage of the available API function. There are certainly other ways to skin this cat, but this is my favorite.
There is a default feature in the policies that allows for a maintenance override of the prevention policies so that general admin tasks can be completed. Let’s think about that disgruntled backup admin scenario. The best option to prevent this is to create two policies, one that allows for policy override and one that does not.During normal operations, no policy override is allowed. When a maintenance window is approved a security engineer can apply the policy that allows override and then revert back to the more restrictive policy at the end of the maintenance. We now have appropriate segregation of duties, the disgruntled backup admin can no longer elevate his own privileges.If the security admin is smart, they will automate this process by taking advantage of the available API function. There are certainly other ways to skin this cat, but this is my favorite.
-
Restrict The Network
The global network policy is defined as *.*.*.* for both inbound and outbound traffic. Which is a wild card allowance for all traffic; which means that by default all the information must flow.Depending on your needs you can start to lock down network access to the appliance. Perhaps you have a network segmentation policy governing your decisions, and you have multiple sets of backup appliances on separate networks.Even though you have firewalled these networks from each other, you still allow SSH through due to the nature of the beast. Can you craft a policy that allows you to accept SSH traffic within a subnet of appliance hosts, but at the same time prevents SSH traffic from one appliance to another if they are in separate network segments. Yes, yes you can.
The global network policy is defined as *.*.*.* for both inbound and outbound traffic. Which is a wild card allowance for all traffic; which means that by default all the information must flow.Depending on your needs you can start to lock down network access to the appliance. Perhaps you have a network segmentation policy governing your decisions, and you have multiple sets of backup appliances on separate networks.Even though you have firewalled these networks from each other, you still allow SSH through due to the nature of the beast. Can you craft a policy that allows you to accept SSH traffic within a subnet of appliance hosts, but at the same time prevents SSH traffic from one appliance to another if they are in separate network segments. Yes, yes you can.
-
Get It All In Once Place
- Even if choose not to dive deep down into the rabbit hole of customization, the agents are going to generate a number of events with their baseline configuration. These events can be invaluable to a SoC and are a critical correlation point for activity on your backup systems.Get all your agents reporting back to the DCS: SA management server and then use your SIEM of choice to pull the logs out of the database and into your correlation hivemind. Make your auditors smile, they deserve it.
Ok enough with the words, wrap this up so I can get back to browsing Reddit….
Before you go, two things; threat modeling is your friend and read the fine print. You’ll find some happy surprises like the “free” security agent you get when you purchase your backup appliance. It is likely that the OEM relationship will continue to exist between Symantec and Veritas for some time. So long as that lasts, you won’t have to scratch your head when the security team raises red flags on your Netbackup implementation, and if you’re the appropriately paranoid security engineer, you can rest assured that even though your corporate parents got divorced, they still love you just as much.
