Are we as security practitioners willing to 'eat our own cooking'? In other words, are security professionals practicing what they preach with respect to compliance at the organizational security function level? A recently leaked US Office of the Inspector General (OIG) report pertaining to the Department of State’s Bureau of Information Resource Management, Office of Information Assurance (IRM/IA) is a good reminder to those of us in the field.
In this case, the IRM/IA allegedly failed to comply with agency project management requirements (over which it presumably enforced compliance) with regard to its iPost tool. “iPost” is the custom application that continuously monitors and reports risk on the State Department’s IT infrastructure. The report states “…the OIG team found no project management documentation or evidence of the office following any project management methodology for the development and maintenance of iPost during its life cycle.”
We all may be tempted to cast stones at the State Department’s IRM/IA, but if we examine our own organization, a good majority would be able to recount similar stories where security people turned their heads with respect to enforcing compliance of systems for which they were responsible.
Compliance with security policies and procedures by security people is important. Just because we are responsible for making sure that OTHERS comply does not mean that we don’t have to prioritize our own compliance.
Bearing the inconvenience of complying with security rules is a shared responsibility and can actually prove to be beneficial to the security professional. For instance, when those who perform assessments of security controls are also charged with implementing those controls, that person gains a much better understanding of the impact security rules and procedures have on the use and operation of an information system, hopefully leading to practical adjustments and fixes that balance security and operability. Thus, self-compliance enables one to fine-tune requirements and procedures so that they are more practical, understandable and are implemented more efficiently.
The ultimate embarrassment is when the security function allows its organization’s computer systems to be exploited through a security vulnerability or weakness in one of its own information systems. Intrusions of agency networks and compromises of its data are bad enough in themselves, but when systems owned by the information security office are the cause, there is very little tolerance.
A failure by leaders of the organizational security function to meet or attempt to meet the requirements they impose upon others greatly jeopardizes their credibility and calls into question the professionalism of the information security team. Although there may be a temptation to skimp on self-compliance, clearly the better alternative is to secure one’s own systems first and best.