Deadlines and DevOpsRapid development and deployment of new applications and software, also known as DevOps, is the cornerstone of most IT organizations today. The DevOps model is expanding, and the ability to implement a new tool before a competitor does often result in significant revenue when it is done properly. Weighing the risk of rapid time to market vs. security and regulatory requirements is a difficult task for any organization. Fast release cycles sometimes shorten test and quality assurance time, so software can sometimes be released without thorough testing. In order to meet deadlines, sometimes change control processes are set aside. Most often, users are granted much more access than they require to deliver on time.
A Matter of ConvenienceAside from DevOps, other user communities within an organization often request broad access as a matter of convenience. Some of the more common reasons users request full administrative access for their endpoint (Mac, PC, Linux) are:
- Collaboration tools do not meet the needs of users or are not available
- Email restrictions prevent moving large files from place to place within a network
- Installation of approved software or updates require administrative access
- It takes too long to get the support needed to do things they consider basic
- The software they want to use is not on the approved list, so they need rights to install it themselves
"I Want It All” – Queen, 1989Faced with a desire for convenience, short deadlines, and sometimes unknown variables, the typical user community will request “full administrative access” to servers and endpoint computers. In many cases, they ‘don’t know what they don’t know’, so the simplest solution is to ask for everything so they are prepared for anything. With full administrative access, it is possible that the end-user may not confine their activity to the specific reason for which it was granted, and this presents a greater risk to the corporation. Compliance teams should be concerned about the possible installation of unapproved, unsigned, or unlicensed software that may expose the environment to much greater risk, or the corporation to liability with regard to licensing. Granting users broad access brings this risk to the forefront, among many other concerns.
It’s a Question of RiskEvery group of users is driven by a different agenda or set of requirements, and weighing the risks of their requests against the risk to the organization can be the difference between success and failure for any company. In a typical end-user environment, users are not expected to have a broad understanding of the risks associated with granting broad administrative privileges to their laptop, or PC. Development teams are usually driven by other priorities and sometimes they neglect to consider the security or policy implications of delivering their project on time. The risk to the corporation is very real, however. Simple changes to configurations like taking down a firewall, or sharing a folder can permit access other than what was intended (“It’s too time-consuming to pick specific users to share with, I’ll share with everyone.”, “I’ll open that port, only ‘Bob’ will know it’s available.”). Once the endpoint is accessed, data is exposed, and sometimes other aspects of the system are compromised. Imagine a simple change that a user with ‘root’ privileges made that exposes the intellectual property, potentially patentable information, financial records, or any of a number of other things found in a corporate environment. The outcome could completely compromise the integrity of the company, impact shareholders, leak confidential research or expose confidential information. Other things that are done for convenience can have an even greater impact. Savvy users may use privileges to access an endpoint, circumvent security controls, and access corporate information that they should not access, so it is important to control access to everything from the endpoint to the servers. The responsible thing to do is to put controls in place that weigh convenience vs risk, and permit only the access that is required to protect the company as a whole.
Quantifying the Potential Risk – Taking a “What If?” ApproachEvery corporation or entity has varied requirements for compliance. These range from policies established by the Board of Directors and Shareholders, to regulatory requirements such as GDPR, HIPAA, SOX, or others, and sometimes just common sense. Some of the considerations when evaluating risk in any environment are the potential for:
- Brand damage resulting from a compromise or negative press. This can be very difficult to quantify, and it is often best to consider things in the worst case since stock prices may be impacted and overall company value could fall.
- Regulatory fines. Many regulations apply to how data is handled, and who should have access to this information. Failure to comply with these regulations can result in significant fines or penalties and are often accompanied by brand damage.
- Audit failure. Most regulatory standards (and common sense) require that all privileged access to systems be monitored and strictly controlled. Failure to comply with this standard may result in both regulatory fines and brand damage.