AuditScripts Policy Update for GDPR

Hello, friends and subscribers. As you know, the European Union’s General Data Protection Regulation (GDPR) is almost here and it is has become an everyday topic of conversation in our data protection circles. If you are an information security person, I hope you have made friends with the privacy folks in your organization, and vice versus. Data protection, especially under terms of GDPR, will involve the security and privacy teams working together.

As most of you know, GDPR goes into effect on May 25, 2018 and it was created to better harmonize data protection laws around the member states. Key components of GDPR include data subjects’ right for rectification, right to fair and lawful processing of personal data, as well as the right to erasure. Basically, GDPR addresses two core principles: Data Protection and Privacy.

Here at Auditscripts.com, our team knows data protection and we have tremendous expertise in information security architecture. We believe in the importance of privacy programs. In this updated release of the policies, we have acknowledged that privacy management is a unique discipline. Our recommendation for organizations is to create a Privacy Program, starting with a Charter that defines the goals of the Privacy Program. We have included an updated privacy policy in our subscription to document how privacy efforts interact with information assurance, governance, and technical controls, but this is not a replacement for a comprehensive and well documented privacy program. If you are in need of privacy resources,

The International Association of Privacy Professionals (IAPP) provides guidance, articles, and an active community supporting other privacy professionals at https://iapp.org/.
Project Management Institute provides information on project management and program management at www.pmi.org .

Today, we release our updated policy library to address the principles and requirements of GDPR, and this blog will highlight the key principles surrounding the updates to the policies.
Guiding Principles in the Creation of This Update (2018 2.3)

 

We Baked Data Protection Principles into the policy library as a whole.

The term ‘Data Protection’ is used frequently in the GDPR Articles and Recitals, but this is nothing new to our policy library. We have created an Information Assurance Policy library for you that already addresses key data protection principles of confidentiality, integrity, privacy, and availability.

We give you the tools to establish a Governance, Risk, and Compliance Program that can support data protection practices under that a GRC umbrella.

We wrote policies for a Multi-Disciplinary Team Approach to Successful Data Protection. Some examples include:

Executive Support for Governance, Information Assurance, Risk Management, and Privacy efforts

Privacy experts reviewing privacy notices

Legal personnel vendor agreements

Risk expects conducting assessments

Information Security architects reviewing technical controls

We Updated policies names to include updated concepts.

Data Protection and Classification Policy has been refined to more closely tied together data classification efforts supporting data protection (formerly, Data Classification Policy)

Data Retention, Backup, Archive Policy includes updated policy statements to reflect handling of personal data

We Avoided Regional Favoritism

We chose open-ended language in the policies to maintain a balance between the requirements of the EU’s GDPR and other geographical region’s privacy and data protection regulations.

Open ended statements that cover all regulatory bodies without being specifically written for one geographical regulatory body. For example, for GDPR, we implied that your organization is the data controller without using that term specifically.

We used the term ‘personal data’ to be inclusive of multiple regulations that refer address data about individuals.

We acknowledged that GDPR Expertise will evolve and grow as the Regulation goes into effect.

As Data Protection Authorities (DPAs) begin to review factors surrounding data subjects’ complaints and data breach notifications, we will better understand how to apply administrative and technical controls to mitigate risk.

As of the writing of this blog post, there is uncertainty of the EU-U.S. Privacy Shield and there are lingering questions if United States companies should certify or not.

We updated all policies. These policies received the largest updates:

Charter Document for Information Assurance

Cloud and Third Party Services Policy

Data Backup, Retention, Archive Policy

Data Protection and Classification Policy

Incident Management Policy

Privacy Policy

Thank you for participating in our community and we will continue to provide guidance and suggestions on how to best use the resources on www.auditscripts.com .

The Digital Security Poverty Line

Like many information security practitioners, this week marks the return to the office and reflection after attending the annual RSA Conference in San Francisco. Every year there are interesting speakers, some better than others, crazy parties, and a vendor show the size of a small city. And every year I admit I get a little contemplative at the end of the week and try to reflect a little more on our industry.

This year there was a phrase that I heard that got me thinking, the phrase described the challenges of the “Digital Security Poverty Line.” So it got me thinking, is this a real thing? Is this hype or when we look at organizations today are there really haves and have nots in the world of information assurance?

I think one of the first discussion points has to be a monetary one. Do larger organizations have larger budgets when it comes to information assurance? I think the knee-jerk reaction most of us would have to this is yes. But a better question might be – do larger organizations have a larger percentage of their budget allocated to information assurance? According to a study performed by BAE Systems Applied Intelligence and the Gartner Group there is a wide range of spending that organizations allocate to information assurance. According to their October 2013 study (http://blogs.gartner.com/john-wheeler/it-security-budgets-rise-as-data-breach-fear-spreads/) the majority of organizations allocate between 3-10% of their IT budgets towards information assurance efforts. 

2013itsecuritybudget

But this still begs the question – does that mean if your organization allocates lower than 3% of its IT budget on information assurance, does that mean your organization is in poverty?

For this statement to be true, there would have to be a set of organizations under-allocating resources – which likely is true. But also the industry would have to be lacking in low cost quality tools that could be used to secure information systems. So is that true?

This is where I think the phrase starts to break down. Yes, in my opinion, there are and there always have been low cost tools available to small, midsized, or “poverty stricken” information assurance departments that could be used to secure information assets. While certainly it would be nice if everyone could afford a tool like Tenable’s Security Center, Tenable has always been gracious enough to provide tools like stand-alone Nessus if your organization did not have the funds for the larger solution. And of course this does not even take into account the abundance of free or open source (FOSS) tools that companies could employ – OpenVAS anyone?

I can certainly understand the vendors point about the appearance of a poverty line. And more importantly I think it’s quite generous for companies such as Qualys and Tripwire (nCircle) to release tools for small businesses to help them alleviate the stress. For those of you would did not notice, both of these vendors released free tools at the RSA Conference to help SMBs to secure their information systems based on the recommendations from the Critical Security Controls project.

So free or low cost tools are available to organizations. So if there is a poverty line, then it would have to be related to the personnel resources that an organization allocates to the issue. In the long term automation will help to remove this as a consideration, but as organizations initiate their assurance programs, it will take people to kick things off and create a strategy for organizations. Certainly that’s hard to argue against.

So, is the idea of a digital poverty line real? That’s hard to say. It could be the emergence of a new trendy marketing word. Or on the other hand if one does exist today I would argue that is has to do with the allocation of personnel and not the allocation of capital budgets. So what’s the moral of the story? If a digital security poverty line exists, it is because of their personnel. So if I was an organization today reading about data breaches and theft of intellectual property I would make sure I’m investing in the people that keep my data secure. Am I giving them the training and mentoring necessary to make good decisions for the organization or am I simply throwing my capital after more products. Maybe it’s time we all followed after groups like the State of Colorado and spend fewer resources on software licenses and fancy appliances and more on investing in the people that watch over our organization’s data every day.

Steps to Creating a New Metrics Program

Metrics definitely seem to be a buzz word in information security circles these days. It seems that I can hardly give a presentation or meet with clients without the topic coming up at some point in our discussion. But to be fair, I think these discussions are healthy and I’m glad to see so many people beginning to ask the question, “how can I measure my efforts in securing my organization’s data?”

My fear though, is that there are a number of organizations who see other organizations implementing metrics and they believe that they can skip the core foundational program steps and jump right to interesting dashboards and metrics. It’s like watching someone who never exercises observing a marathon runner and saying, “I think I’d like to run a sub-four hour marathon too this year.” Without establishing a base and putting in the effort to practice, achieving great results can be difficult to impossible.

So this begs the question, in terms of information security, how would you build a base, and what steps could you take to lay the foundation for a solid, mature information security program. After working with our clients for the past 10-15 years, this would be our advice:

  1. Obtain a security management charter from senior management
  2. Create an organization wide IS Steering Committee
  3. Document your organization’s overall security goals
  4. Create & approve appropriate security policies, procedures, & standards
  5. Educate your organization on those documents

Then what? If we finish those steps, then can we start a metrics program? Absolutely! Once you have a proper foundation and you know what your organization is trying to achieve, then I think it’s a perfect time to kick off a program to develop metrics in your organization. But take it one step at a time. Don’t try to bite off too much too quickly. Take it slow, achieve results, and then progressively add to the sensors and data you collect.

  1. Here are the steps we would take to start your initial metrics program:
  2. Identify what information security sensors you have already successfully deployed
  3. Determine what meaningful metrics can be gleaned from these sensors
  4. Deploy a tool that can centrally aggregate, normalize, and report on the data collected by the sensors
  5. Create basic reports based on the metrics from strep #2
  6. Work with business owners to remediate risk

Our best advice though is this: achieve value from a small number of metrics first, and then grow your program. If you can’t achieve value from a small number of measurements, you certainly won’t achieve value with a greater volume. Eat that elephant one bite at a time.

Basic Steps for Executive Engagement

Recently a met with an organization who mentioned to us that they had identified executive engagement in information security (or lack thereof) the biggest risk to their organization. It’s not to say that the organization’s executives didn’t care. The issue was that this organization had its hands in a number of other important activities, and securing the organization’s assets simply was not one of their top concerns.

But this raises a few questions – What does it mean for executives to be engaged in information security? How much buy in is enough for management? Is there a bare minimum standard for executive engagement?

So we started thinking, executives have a lot on their plates, so what should a busy executive do to sponsor an information security program without getting sucked into a black hole of too much engagement and allocating too much of his or her attention to the program. It seems to me executives have the responsibility to ensure that all the plates are spinning in the organization to continue pursuing the overarching business strategy. It takes a number of moving parts to achieve an organization’s mission. So what steps should they take to make sure the information security plate stays in the air?

Step One:            Assign an information security champion (think senior project manager).

Step Two:            Sign a charter for an information security steering committee, or add security responsibilities to the IS steering committee’s charter.

Step Three:        Task the steering committee with documenting policies & procedures for how information security will take place in the organization.

Step Four:           Support the steering committee in their efforts with other executives and in front of the organization as a whole.

Step Five:            Monitor the committee’s progress and encourage them along the way.

Remember this is a journey, not a destination. This is a program, not a project. But like any part of an organization, the information security team needs executive support and guidance in order to help the organization to achieve their goals. Security is expensive and requires effort, but when balanced with other aspects of the business it can help the organization to be healthy and succeed in the long term.

Elements of an Information Security Charter

Part of any solid project / program management effort is a program charter that defines the program in order to ensure its success. Too many times projects begin without a clear definition of success and as a result it becomes very difficult to measure success or often even to make progress on the project in any way. Information security programs are no exception.

In order to have a successful information assurance program, organizations need to take the first step of creating a charter for the information assurance team. The benefit of these charters is that they should function in the same way as any other program charter. Because of that we have a solid body of knowledge available to us as to what elements should exist in a mature program charter.

Elements of a mature information security program charter should include:

  • Name / Title
  • Start and end date / timeline
  • Approval authorities / executive sponsorship
  • Team leadership / management
  • Key players / stakeholders
  • Business case / purpose / regulatory requirements
  • Problem statement or opportunity
  • Business benefits
  • Measurable performance outcome / metrics
  • Scope of work
  • Key milestones
  • Roles and responsibilities
  • Manpower and budget requirements
  • Barriers to success and risks
  • Communication plan

If you haven’t taken the time to define a program charter for your security team, why not start now. Not only will this process help to define the goals of your effort, but it can focus your team’s efforts and align executives with the team’s efforts.

References:

http://www.sixsigmadigest.com/project-charter.shtml

http://en.wikipedia.org/wiki/Project_charter

http://www.agilebok.org/index.php?title=Elements_of_a_Project_Charter_for_an_Agile_Project