One of the oldest rivalries in IT is that between security of the application and the performance and ease of the...
application. Both sides claim to have volumes of data to support their superiority. Although it might seem inconsequential to the layperson, this is no small debate. System administrators are often forced to do the impossible, maintaining performance levels by keeping systems running in order to provide the speed and flexibility that businesses need. Administrators cannot afford to have anything slow them down performance-wise, lest someone else beat them to the finish line. Security professionals must ensure that their applications are locked tight against external and internal threats, including hacking, data loss, corruption and theft. Any of these security risks can put a company on the front page of local -- even national -- news, which is never good for the bottom line.
Although security and performance groups have different goals, they both have the company's best interests in mind. The fact of the matter is that these two opposing sides aren't struggling against one another so much as they are against time. A system admin needs to reduce the time to market and ensure performance for his servers and applications. He needs to streamline processes to keep up with business. Security people need time to make the proper provisions to ensure that the application is protected against data loss before it's released. It's up to both sides to work together to find a way to balance security and performance to meet business needs.
Say goodbye to the layered approach
The best way to balance security and performance is to start at the beginning. When I say beginning, I mean the base template or build document, if you're in a physical environment. For many, the first time they hear the term server hardening is after the build has been completed. This tends to favor a security overlay process after other steps have been completed. This has become a major issue, as security -- or anything else beyond the purview of the system admin -- is looked at after the fact. This concept is called a layered approach and it often inefficient, making it difficult to balance security and performance. Although it goes against the long-held mentality of the assembly line, abandoning the layered approach can yield surprising benefits in security, performance and, most importantly, time.
Sharing security responsibilities
Doing away with the layered approach isn't as difficult as it might seem. In fact, with a few key steps, it's pretty simple. Start by considering the desired end state and what it will take to get there. Has the security personnel ever seen a build document? Has the system admin seen the security requirements? You might be surprised to learn that the answer to these questions is often "no." If both groups took a moment to step back and carefully consider things, they may find that a new document is needed in order to create an entirely new build that satisfies both of their needs.
This could result in the system admin getting slightly involved in the security process by completing a few security steps in the initial build. For example, he may have to enable firewalls with at least a baseline protection scheme, or disable and modify accounts before the server ever reaches the security group. This may sound like more work for the system admin and, to be fair, it is. However, providing a server with an acceptable baseline security profile reduces the amount of time the security team spends on it, resulting in a faster overall deployment for the requester.
Finding a balance boosts performance
There are other benefits to the system admin working closely with the security team. If the system admin is helping to put in security controls, he also has the ability to help shape the security baselines and recommend adjustments that could improve system performance. This could entail something as simple as firewall or scanning configurations, or dictating what tweaks should be excluded from logging and reporting. Being involved from the beginning of the process allows both groups to better achieve their security and performance end goals. This benefits the company as well, as this collaboration opens the door to the possibility of automating parts of the security process.
There is no magic formula or shortcut to avoiding the performance impact that increased security can have on both your server and the deployment process. The best way to balance security and performance is to embrace security needs as a common core component of your server build rather than view them as a hindrance.
Preparing for a system admin job interview
Build an enterprise application security program
Don't burn bridges when leaving a system admin job