Just like fashion or what TV shows are interesting it seems technology and security also have fads, trends, things that are in, and things are are out.
Ten years or so ago risk management was very new, untested, and frankly most organizations didn't do it, didn't want to be bothered by it, etc. They just wanted to get on the Internet and make some big gobs of money. If there was a security team (or individual) they were likely a system administrator who was identified as being "the security guy" as well. Not a full time responsibility and 80-90% technical (virus fire fighting, firewall rule management, maybe some high level policies).
With a more compliance driven world the rise of professionals who took security to the next level arose. Those individuals started maybe as auditors, system admins, or other IT roles - but then they were asked to work with Audit to map out the open audit issues and plan for "managing" the risks or managing the residual audit findings. This was one of the first steps toward Risk Management. In many organizations the concept was that any exceptions to the security policies must have a documented risk acceptance and have a plan to address the issue(s) (and have executive sign off as part to ultimately accept the risk).
As more and more complex compliance requirements continued to evolve, many organizations then looked to the risk management team to help to translate these requirements from legislation, laws, rules, or other external drivers and create tangible controls that then could be measured and implemented.
Along about this time organizations started focusing more and more on the process of establishing controls and measuring them that some organizations started to take the technical security role for granted. It is great to have a list of 1500 controls in your environment, but if you don't have a team of technical security professionals that are responsible for implementing and maintaining those controls you will have created a self fulfilling prophecy of non-compliance for your organization.
A couple years back I saw the start of a backlash against anything that hinted of risk management - to the point that many "security" bloggers and commentators blamed "risk management" for all of the intrusions and exploits. Needless to say this is a bit off the mark.
Here is an example of an article that slams Risk Management
https://www.infosecisland.com/blogview/14329-Security-Stupid-Is-As-Stupid-Does.html
Security is not risk management, and Risk Management is not security.
Both aspects are required to maintain a good governance of an environment. Anyone who's worked with my has heard me refer to them as a Yin-Yang relationship. Security is the technical control implementation group, they contribute to the creation and implementation of standards, they are the ones that you call in when you have an event that you need researched and are key in incident handling. The technical security team is who you look toward if you have a new technology and you need to have a technical assessment done.
Risk Management helps to establish the policies and standards, and makes sure that they align with the business goals. They interface with the business to represent security during the life cycle of a project and act as trusted advisers to the project team, helping them to make sure that the project, solution, or changes, all match company policy and best practice. The Risk Management team also will document any residual items that can not comply with policy/standards and work with the technical security team to determine the right type of mitigating controls to keep the environment secure as the system becomes compliant.
These two groups both need to work within the goals of the business and help to enable business to happen securely.
Ten years or so ago risk management was very new, untested, and frankly most organizations didn't do it, didn't want to be bothered by it, etc. They just wanted to get on the Internet and make some big gobs of money. If there was a security team (or individual) they were likely a system administrator who was identified as being "the security guy" as well. Not a full time responsibility and 80-90% technical (virus fire fighting, firewall rule management, maybe some high level policies).
With a more compliance driven world the rise of professionals who took security to the next level arose. Those individuals started maybe as auditors, system admins, or other IT roles - but then they were asked to work with Audit to map out the open audit issues and plan for "managing" the risks or managing the residual audit findings. This was one of the first steps toward Risk Management. In many organizations the concept was that any exceptions to the security policies must have a documented risk acceptance and have a plan to address the issue(s) (and have executive sign off as part to ultimately accept the risk).
As more and more complex compliance requirements continued to evolve, many organizations then looked to the risk management team to help to translate these requirements from legislation, laws, rules, or other external drivers and create tangible controls that then could be measured and implemented.
Along about this time organizations started focusing more and more on the process of establishing controls and measuring them that some organizations started to take the technical security role for granted. It is great to have a list of 1500 controls in your environment, but if you don't have a team of technical security professionals that are responsible for implementing and maintaining those controls you will have created a self fulfilling prophecy of non-compliance for your organization.
A couple years back I saw the start of a backlash against anything that hinted of risk management - to the point that many "security" bloggers and commentators blamed "risk management" for all of the intrusions and exploits. Needless to say this is a bit off the mark.
Here is an example of an article that slams Risk Management
https://www.infosecisland.com/blogview/14329-Security-Stupid-Is-As-Stupid-Does.html
Security is not risk management, and Risk Management is not security.
Both aspects are required to maintain a good governance of an environment. Anyone who's worked with my has heard me refer to them as a Yin-Yang relationship. Security is the technical control implementation group, they contribute to the creation and implementation of standards, they are the ones that you call in when you have an event that you need researched and are key in incident handling. The technical security team is who you look toward if you have a new technology and you need to have a technical assessment done.
Risk Management helps to establish the policies and standards, and makes sure that they align with the business goals. They interface with the business to represent security during the life cycle of a project and act as trusted advisers to the project team, helping them to make sure that the project, solution, or changes, all match company policy and best practice. The Risk Management team also will document any residual items that can not comply with policy/standards and work with the technical security team to determine the right type of mitigating controls to keep the environment secure as the system becomes compliant.
These two groups both need to work within the goals of the business and help to enable business to happen securely.
Comments