If you would like to read the other parts in this article series please go to:
- Security: A Shared Responsibility (Part 1)
- Security: A Shared Responsibility (Part 3)
- Security: A Shared Responsibility (Part 4)
- Security: A Shared Responsibility (Part 5)
- Security: A Shared Responsibility (Part 6)
In this multi-part series, we’re taking a look at the big picture of security areas of responsibility and how each component (internal job position or external entity) fits into the puzzle, with a discussion of the importance of defined areas of responsibility. In the first article of the series, we looked closely at the role of the CSO or CISO, at the top of the IT security structure. Now, in Part 2, we’ll continue the discussion with an examination of the security role(s) of IT administrators, and then we’ll talk about the responsibilities of outside contractors, consultants and partners to whom you grant access to some or all of your IT resources.
The IT admin’s role in security processes
The typical IT administrator is understaffed and overworked, just keeping the network running, troubleshooting technical problems and fielding complaints and requests from end users. Admins are already responsible for a multitude of things: upkeep, configuration, maintenance and management of servers, desktops and mobile devices that connect to the network. The last thing an admin wants to think about is security.
Security makes an admin’s job tougher. Security measures make it more likely that users will have problems accessing the resources they need, resulting in even more complaints and pleas for tech support help. Security technologies often slow down performance, creating aggravation for IT and end users alike. Security inconveniences and frustrates everybody, requiring the memorization and entry of long, nonsensical passwords, denying access when you leave your smart card at home, and adding a layer of complexity to the technology that provides more opportunities for software bugs and more likelihood that things will go wrong.
Administrators may be stuck implementing security policies with which they don’t agree, and/or deploying security technologies they don’t understand or in which they don’t have confidence, having had no input into the policy-making and purchasing decisions. As you might guess, this is not the best recipe for achieving an effective security solution.
If IT admins are tasked with the hands-on jobs involved in carrying out the CISO’s decisions, such as installing and configuring security solutions, as well as troubleshooting and maintaining them, it helps to get them in on the process at the beginning so they can provide input from the operational viewpoint. Admins know the network intimately and may know reasons that a particular security mechanism will or won’t work well in their environment.
In addition to general IT admins, large organizations are likely to have specialized admins, such as the Exchange (or other mail server) administrator, the webmaster(s), the firewall administrator, the database administrator, the telecommunications administrator, etc. Each of these will have responsibilities in relation to the security of their specific products or services.
Organizations may also have designated systems security administrators. If the CISO’s role is to develop and oversee the security policies, the security admin’s role is to implement those policies. This takes some (but not all) of the security burden off of the general IT admins and the specialized admins.
In the same way that your technological security strategy should be multi-layered, with different mechanisms providing protection for data as it travels across the Internet, at the perimeter, in transit on the internal network, at the local system level and at the data storage level, your security personnel structure is also more effective if it’s multi-layered. The security admin serves as a layer between the CISO and the general admins. In this case, since the security admin is the hands-on implementer, he/she should have input into security policies and decisions in the early stages rather than after the fact.
The security admin is tasked with ongoing monitoring of the network and systems for security violations and vulnerabilities. Penetration testing can reveal weaknesses in the security implementation so that they can be addressed before attackers discover them.
It’s important for all administrators – general systems admins, specialized admins and security admins – to work together under the direction of the CISO or CSO to make security a priority. Different orgs will divide and assign security-related duties differently, but it’s important that everyone involved know who is responsible for which tasks.
For example, does the responsibility for testing and installing regularly released software patches fall to the security admin or the IT admin? Will specialized admins handle the patching of their particular servers themselves or will one person be responsible for all patching of all servers and clients? What about mobile devices, especially BYOD devices? Will you leave it up to the users to keep them updated (not a good idea) or if not, who is responsible? These are questions that need to be answered and made a part of your written policies and procedures.
The role of outside consultants, contractors and partners
It would be a mistake to think that the security of your organization’s network, systems and data is only the province of those who are directly employed by the company. Anyone who has access to your internal network or to systems and devices that connect to it has a responsibility to maintain security best practices so as not to put your assets at risk.
Unfortunately, you can’t always expect outside consultants, contractors, partners and others to whom you grant access to be implementing the highest levels of security on their connecting systems on their own. That’s why your security policies need to be explicit about requirements, and you should use heath-checking mechanisms for remote access systems to ensure that they have the latest updates and service packs, have anti-virus installed, updated and enabled, have firewalls configured, and so forth.
Large enterprises are in a better position to enforce strict security policies for outsiders who have access to the IT infrastructure, and some even issue their own hardware to consultants and contractors so they will be able to manage those systems in the same way as those of employees. This reduces the risk that consultants and contractors bringing their own laptops and other mobile devices will introduce malware that was picked up from another network.
Smaller companies and non-profits on tight budgets not only aren’t able to afford such measures but also are likely to be dealing with smaller, less expensive consulting firms that may not have their own structure security practices.
In either case, having outsiders access your network and systems always poses an additional risk to the company; it’s just a difference of degree. Outsiders will not be as familiar with your network and that lack of familiarity can cause them to inadvertently make mistakes that lead to an unintentional security breach or data leakage.
When bringing outsiders into your network – whether it’s for a day or for a long-term assignment or partner relationship – it’s important to set ground rules and to set up technological enforcement of those rules. A frank talk about security before hiring a consulting firm or contracting with a third party for outsourced work is in order, and specificity about security issues should be written into the contract. Be wary if they try to shrug it off with broad assurances that “you have no reason to worry about security” and are reluctant to discuss exactly what security measures they use. Utilize third parties that have a known reputation for good security practices and talk to references before hiring.
Contractors, consultants and partners will often want to access your network remotely, and you should make sure to use strong authentication for remote log-ons. It’s a good idea to require additional authentication if/when an outsider logs on from a new device or location, and to use multi-factor authentication to reduce the risk of a hacker discovering passwords from a careless contractor or consultant.
When contractors and consultants work on-premises, you have to be concerned about physical security in addition to IT security. This is a concern because you generally are less able to vet individual third parties than when you hire your own employees. You usually contract with a company, and that company is responsible for background checking and monitoring the integrity of its own employees. Your contract should hold the contracting firm legally liable and impose penalties for any breach committed by its employees. You can even ask to see the background checks done on the contracting firm’s employees. If they haven’t done any, that should be a red flag in the hiring process. You might also want to include a non-disclosure agreement (NDA) in the contract if the contractor or consultant will have access to data that constitutes trade secrets or other proprietary information.
Because they go into many different companies, unethical contractors and consultants are in a perfect position to engage in corporate espionage. It’s important to ensure that third parties are always escorted by a trusted company employee when they go into areas where sensitive data is stored or where critical infrastructure components are located, such as the data center or server room. They should be required to sign in and out when they enter the premises, and be given physical access only to the areas necessary to do their work.
In Part 2 of this series on security as a shared responsibility, we looked at the roles of IT administrators – general systems admins, specialized admins and security admins – and then examined the security responsibilities of third party contractors, consultants and partners who have access to your IT infrastructure and assets as part of the relationship. Next time, in Part 3, we’ll begin by looking at the security responsibilities of end-users.
If you would like to read the other parts in this article series please go to: