What you need to do for MA 201 CMR 17 compliance

What you need to do for MA 201 CMR 17 compliance

Date: Jan 04, 2011

MA 201 CMR 17 requires a lot of enterprises that hold sensitive personal data, but there are provisions for compensating controls based on "feasibility," or, whether an organization has the resources available to comply.

In this video, expert Richard Mackey outlines the steps that every organization must take for MA 201 CMR 17 compliance, detailing which requirements apply to all, and which are more malleable.

Topics include:

  • Background (1:49)
  • Specific requirements (3:23)
  • How to decide which controls to implement (12:15)
  • Feasibility (21:43)
  • Risk management (26:33)
  • Training and awareness (34:21)
  • Encryption (36:47)
  • Summary (37:54)
  • About the author:
    Richard Mackey is Vice President of SystemExperts Corp.

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.  

What you need to do for MA 201 CMR 17 compliance

Richard Mackey: It's a risk based regulation and that leaves everybody questioning
all right, well how does that apply to me? If I know what my risks are, how
little do I need to do to comply versus how much do I need to do to comply?
And I'm going to try to answer where some of those gray areas are and give
you some advice on where you may be able to find some leeway from both, the
risk assessment point of view. Understanding what your risks are and what
you should do, what controls you need to implement, and where you don't
have any leeway. Now again this is all my opinion. So take it with the
goodwill that it's intended, but the point is that's what this presentation
is about. Is trying to get you to understand where risk plays a part in
your assessment of which controls and the depth of which controls you need
to apply.

A little background on the law. The requirements and how they apply to your
organization. What the risk language is inside the law, and risk factors
are inside the regulation. I should say, that the regulation recognizes as
being issues that would affect an organizations controls, and how they
would apply them. How you assess risk. I'll talk a very brief risk
assessment methodology, because that's part of one of the controls you need
to have in place, is you need to actually have a formal and repeatable risk
assessment methodology. And then some of the program elements that might be
affected by the risk, and the feasibility of implementing controls in your
environment, and then finally a summary.

The law requires you to have a written information security program, and
you can't avoid this. You have to have this stuff written down. It also
requires general controls that all companies should already have in place.
If you're a medium to large sized business, chances are you have some of
these, most of these controls in place. You're going to have a general
security policy, a regular maintenance of the program, and you have some
identity and access management in place. To make sure that only the right
people get access to the protected data that you're trying to protect. It
also requires specific technical controls, that are not present in most
regulations. Even though there's a significant amount of administrative
controls in this regulation, there are a number of technical requirements
that have not appeared in any. And bear in mind the PCI DSS is a contract
and not a regulation. So even though the controls here are very similar to
those specified in the PCI Data Security Standard, they ha `Ive never shown
up in a law before.

So we've got encryption, vulnerability management, fire walls that are
required. These are all actually specified within the regulation. Now it
actually states inside the regulation,that it is consistent with HIPAA,
GLB, the payment card industry data security standards, and it works to be
consistent with the language that you see in those. In fact, if you looked
at the Data Act it also attempts to be consistent with this law and the
others that we're seeing coming out. So what are the requirements that you
need to have? Well you need to establish a living security program. What do
I mean by living? You actually have to have a security program that is
assessed regularly by the organization, that it's paid attention to. That
it just isn't a set of documents just thrown into a drawer some place. But
you have to have risk assessment in place. Meaning, that you really have to
understand what risks there are to the information that you're trying to
protect, and then implement controls that mitigate that risk. ISO 27001
establishes a set of, a framework for having a security program that would
have all of these elements in it.

Another one that's extremely important, partner management. As I said,
we've been dealing with partner management ever since GLBA required it for
financial companies. But it's an incredibly important part of this, and I
agree that it is, in fact, going to be the motivation for a lot of
organizations to comply with this. And just an aside about what other
motivations there are yeah, I don't think the fines and ad hoc audits are
really going to be the driving factor here. Because I don't know how the
state would possibly justify the cost of going out and auditing people
unless there was auditing organizations, unless there was in fact a breach.
So I think what's going to happen is if you're going to be, you're going to
need to be compliant to be able to talk to your partners, your business
partners and assure them that you are compliant so that they will continue
to do business with you. You also need formal identity and access
management. In fact, if there is anything that is similar to this as you
see in all the other regulations, HIPAA for example, and PCI DSS as a
contract. Is that it's more about the process of allowing access, of
granting access, and the audit trail associated with granting access, and
knowing who has access to what, than it is about the technical controls
that are in place. Although there are a fair number of technical controls
that are required by this regulation.

Then instant response and follow up, and this is kind of interesting.
Because it actually not only requires you to have an incident response
plan, although that's not mentioned specifically, it does say that you have
to follow up after the response and understand what happened, and why it
happened, and what you did, and what you can do better next time.
Encryption, that's pretty clear. Configuration management. Actually making
sure that your systems are configured appropriately, like your firewalls
are configured appropriately. And vulnerability management, virus detection
and patch management. So those are all requirements that come right out of
this regulation. If you'll notice unlike the other notification laws, there
are a whole set of technical requirements in here. So do all of the
requirements apply to you? Well, the safe answer is yes. So why don't you
just do them all and we can finish this talk right now. But the fact is
that the real answer and the way the law, the way the regulation is written
it depends on the risk associated with your business and your ability to
implement the controls. The ability to implement the controls could be
financial ability or technical ability, and that comes under the heading of
feasibility, which I'll talk about.

Now the procedural and administrative aspects of the regulation are almost
impossible to avoid. It would be hard to imagine that you didn't have to
have a written security program, you didn't have to make sure that somebody
was responsible for it, that you didn't have to have training in place,
etc. Because that's just irresponsible in a sense, right? But when it comes
to some of the technical controls, the depth with which you implement them
is going to be based on the risk that the lack of depth might represent to
you. So the idea is that the complexity of your security program has to fit
your organization's risk profile. And as I said, that you can actually
adjust the depth of some of the technical controls to meet the risk you've
assessed. So the objectives of this regulation are to ensure that the
security and the confidentiality of customer information, in a manner fully
consistent with industry standards, protect against anticipated threats, or
hazards, to security, or integrity of such information ,and protect against
unauthorized access to, or use of ,such information that may result in
substantial harm or inconvenience to any consumer. So, that basically means
that this is all about trying to prevent leakage or illegal use of or
access to consumer information. And that's both employees and your
customers.

So the program factors, and this is where we all of a sudden start to see risk
assessment coming into play. The program must be appropriate to A, the
size, scope, and type of business of the person obligated to safe guard the
personal information. So I'll talk more about this later, but smaller
organizations will be allowed to implement less deep controls, less complex
controls, than a larger organization with more information. The amount of
resources available to such a person. So you might be able to get cut some
slack if in fact you can't afford to implement certain types of controls,
or you don't have the personnel to implement the controls in the way
they're specified. The amount of stored data. The more data that's been
entrusted to you, the more you have to endeavor to protect that data, and
the need for security, confidentiality of both consumer and employee
information. So the type of data that you have, whose data you have, and
the type of data that you have. So if you only have Social Security
numbers, or you only have drivers license numbers, or you only have one
type of data. It's much more risky to have more data that is easier to
exploit. Than it is to have less data that might be more difficult, might
require multiple attacks to be able to put the data together to actually
perpetrate identity theft. So this is all about trying to avoid and trying
to prevent identity theft. So the program must be consistent with the safe
guards of personal information of similar character, set forth in any state
or federal regulations by which the person who owns or licenses such
information may be regulated. And if you look at the Data Act the data
accountability and trust Act, you'll notice that it actually supplants
this law. It would be interesting to see how the state reacts if a
federal law is passed, that is supposed to in fact, do away with these
laws. But they're all written so that they're consistent with one another,
which is actually pretty nice.

So this came out of the Frequently Asked Questions that the state put out,
and there are only a few important parts, but I just wanted the whole text
of it here. It talks about the risk based approach in the regulation. So
the regulation adopts a risk based approach to information security. A risk
based approach is one that is designed to be flexible, while directing
businesses to establish a written security program that takes into account
the particular businesses size, scope of business, amount of resources, and
need for security. For example, if you only have employee data with a small
number of employees, you should lock your files in a storage cabinet and
lock the door to that room. You should permit access only to those who
require it for official duties. Conversely, if you have both employee and
customer information data containing personal information, then you're
security approach would be more stringent. If you have a large volume of
customer data containing personal information, then your approach would
have to be even more stringent. So this is from the FAQ, the Frequently
Asked Questions that the state put out. So, the point is that the more data
you have, the more controls and more stringent those controls need to be.
What you want to strive for first and foremost is good security associated
with the data. Because given the fact that we've heard nothing from the
Attorney General about how this is going to be, how people are going to be
audited, or how it's going to be enforced. It's likely that the trigger for
you having to deal with this is going to be a breach. If you can stop the
breaches you can not worry so much about regulatory compliance. This isn't
PCI DSS, where you're forced to have an assessment in every single year, to
prove that you are in fact compliant, right. This is, when bad things
happen, you're going to be called on to prove that you were compliant at
the time of the breach. So, make sure that you are meeting the intent of
the law first, implementing appropriate security controls, reducing that
risk to an acceptable level. And you're well on your way to solving your
problems even if you don't meet full compliance under the regulation.

So the appropriate level of control depends on the risk, on your risks. So
you need to assess your risk to determine the degree you must implement the
controls. And in fact if you look at the other regulations they all
require, like HIPAA, Red Flag Rules, PCI DSS, they all require you to have
a risk assessment methodology and to manage risk appropriately. And it's
amazing the number of companies we run into, who don't have formal risk
assessment methodologies in place, or they do them ad hoc, they're not
really repeatable. So I'll talk a little bit more about risk assessment in
a minute. In fact right now, so the first step in assessing risk is to
assess what we call the inherent risk. That means if in the absence of any
controls, if there were no access controls at all, what kind of risk do you
have. So what you want to do is you want to look at the value of the
information assets that you have. Now we're only talking about personal
information under MASS 201 CMR 17 here. But the fact is the assets that you
manage inside your company that are valuable, are much more than just
personal information. There's strategic information, there's salary data
that you want protected from other employees, there's all sorts of
information that is valuable. But what you want to look at here is, what
kind of value resides in this data? What could someone do with it and how
could that hurt the possessor or the owner of that information, as well as
the company who's the custodian of that information. How attractive is that
information as an attack.

So if someone knew that you had this data, would you be the target of
attack? How much information is there? Because that adds to the value. If I
can get lots of information I could sell this information out in the open
market and it might be worth my while to expend some resources to actually
get that data. So look first, if there were no controls, how attractive you
are as a target. The less information, the less attractive, the less types
of information that would be usable in identity theft, the less attractive
you're going to be. So look at that first. The second is, who has access to
it, authorized access to it? Is it a large community who has access to the
systems and the databases, or is it a really small community? Because all
of a sudden you start realizing there are only a few people who have access
to this, my risk is relatively small. So the controls need to apply to
those people and to make sure that only the right people of those, of the
small group have access to it and these are the risk factors that you have
to consider. So that's the inherent risk.

Okay. How valuable is this stuff? Then what you do, is think about risk in the
presence of controls. So you look at the preventative controls that are in
place. Firewalls, access controls, log ins, passwords all those things
right. And then you say, "oh okay, how good are they? Am I doing a good job
with my firewalls? Am I doing a good job with account identity and access
management, making sure that only the appropriate people have accounts?
They terminate users when they finish, when they no longer have justifiable
access to this information, or they leave the company? "Which are specific
requirements under the regulation.

You look specifically at the ones that are listed in 201 CMR 17. Because
those are the ones that you're required to have and if you don't do a good
job in any one of those, then you're risk is going to go up, right. And
then you look at the detective controls. So most of the methods that are
specified in this regulation have to do with preventing access, but there
are also detective controls. How well could you detect some illegal access
to the data or an intrusion to your environment, and you see how well you
could to it. So you know that you might have to close the door before the
horse is stolen, right? Even though because you realize that there is
something not quite right going on and how effective are those. Then you
look at who the attacking community might be. The larger the attacking
community, the more risk you have. So, if for example the only the systems
that house this incredibly rich set of data only are accessible by people
inside the network. Then the only people who could execute certain types of
attacks, the internal attacks, are going to be your employees. All right,
well then I have to implement controls that are going to be appropriate for
internal access. But if you look at data bases and services that you offer
to the Internet at large, who provide direct access at least to some pieces
of this data, then your risk goes up. And now you're, it puts more of an
owness on you to make sure that you implement those controls effectively.
So you do an evaluation of how those controls are implemented based on how
large a community you have to worry about as attackers.

Then you look at how it might be attacked. So once you have an idea of who
might be out there and could attack, then you look at. All right well, it
could be a bug that I don't know about, a web application, but if you're
not offering over the web that's not a factor that you have to care about.
So then what you do is identify those vectors, and then you try to
understand what the likelihood of that type of attack succeeding is. Then
another one you should think about that either grows or shrinks the
likelihood of attack, is the knowledge availability, that you have this
data at all. So if you're advertising on the web, that you provide a
service that stores all this information and that anybody in the world
would know that, well that's that ups your chance of getting attacked. On
the other hand if you don't, if you only reveal this to a select few
customers for example, or you're providing only condensed information
that's based on this data to outside parties, then it's possible that
reduces the likelihood of an attack. So it might be valuable information
but your not broadcasting the fact that you have this information and that
reduces your likelihood.

Then you start looking at once you look at a specific attack what kind of
technical skills are going to be required to perpetrate certain types of
attack. So, do you have to be a supreme hacker to be able to execute this
thing? That reduces the likelihood very much. Or do you have to be a
systems administrator, to be able to get access to the systems where I
could perpetrate this attack. Again reduces the community of people who can
execute or perpetrate these attacks, substantially. So the idea is you go
through this process of first, understanding what the value of data is, and
then secondly, trying to determine based on the size of the community, the
knowledge necessary how much and the types of information the types of
paths to get to the data, and then determine what the likelihood is.

So risk is the product of inherent risk. The value of the data, and the
likelihood that you've determined, based on all that exercise that you
went through to determine how big the attacking community might be and how
they have to be tooled basically to be able to gain access to the data.
Then what happens, your conclusion is of the risk assessment, is a measure
of the effectiveness of the control that you've deployed. So again, we went
through all the 201 CMR 17 controls and we said "yes, good, good, good,
good, good, good", and that reduced the likelihood let's hope.

So if in fact, you found out through processes that you use not necessarily
technical controls or where you house the data or how you've used
encryption in places, or whatever mechanism, that you've reduced the
likelihood of successful attack reasonably. Without implementing everyone
of those controls that are specified in the regulation, then you may be
able to justify the fact that you haven't implemented those controls,
because you've done compensating process controls or whatever. In fact if
you look at the PCI DSS in fact, there's a whole section in the back that
talks about and is a similar set of controls that are mentioned in this
regulation, but you can actually state a compensating control that achieves
the same intent of any technical control that's actually listed. So I'm
going to state here that I believe that you can make those same statements
under the regulation. Now you prefer not to, but you, if in fact, a
particular control is too expensive to implement, if you can achieve it's
intent through some other method then you may be able to justify it.

So saying you addressed the risk is one justification for a missing or
limited control, and the other factor is feasibility. So technical
feasibility is actually mentioned in the regulation and it can be an
acceptable justification for not implementing the full depth of a control.
And the Frequently Asked Questions mentions encryption of devices. So we
heard earlier that portable devices might be very difficult to encrypt. If
that's part of your, now it's great in fact, I would recommend telling
people prohibit the storage of personal information on these portable
devices wherever possible. But if it's part of your business I mean, if it
absolutely requires you to have your blackberry to have this information on
it, or your laptop, it wouldn't be a problem with a laptop, then you're
going to have to make, then you might be able to argue that it's infeasible
to be able to implement that control. Now you're hanging yourself out there
to a certain degree, but the fact is, that they can't tell you not to do
your business right? So the issue is going to be you're going to have to
figure out whether there are any other ways, any other compensating
controls you can put in place to protect that data from loss or compromise.

Encryption of backups also. If you moved off ten year old data and it's
sitting in some site what's the feasibility of actually encrypting that
even on a move right back. It's like what are you going to do bring a
system out and then re-encrypt it so you can bring it back. I mean the
point is that I think a compensating, a reasonable compensating control in
that case would be entrusting a physical security, some sort of lock box,
or some sort of method for transferring that information without having to
encrypt it that would be just as effective as encrypting the data on the
media itself.

So another one, other areas that might be, you might be able to make the
technical feasibility argument for, is monitoring and law review. If you
don't have the personnel to do daily monitoring for example, of all access
to the systems, then you're going to have to deal with it in some other
way. You're going to have to figure out, oh well I can only do weekly or
monthly or whatever you can actually do. Then another is the depth of
partner practice assessment. It doesn't say how deeply you have to assess
your partners. There's no specification for what it means to assess your
partners, it says you have to assess your partners. So if in fact, you got
a letter from them saying that they complied that may be sufficient. It's
hard to argue that you're going to have to spend twice your budget as a
company to go out and assess every partner as if you do onsite audits of
every single partner you're interacting with. So another area that's
important to keep, to take into account and we've already been talking
about this, is the size and scope. Smaller businesses require less
stringent controls. Why? Because they have less data the assumption is that
there is less data. They're a less attractive target, because fewer people
know about them and there are fewer possible attackers, because they offer
less access to that data. So they either have fewer employees that they
have to worry about or they have fewer customers and they offer less access
to the data.

So rules of thumb that you should take away with you. Let data dictate what
your path is in implementing your controls. The more valuable your data,
the stricter and more stringent those controls should be. So of the name,
address, Social Security numbers, payment cards, driver's licenses, bank
account numbers if you got everything, well I'd suggest splitting them up
number one right, or getting rid of anyone's you don't need. But the point
is that the more of those you have, the easier it will be for a successful
attacker to perpetrate identity theft, and therefore, the more stringent
your controls need to be. Greater volume requires more controls. So if you
have large amounts of customer data, as well as employee data, or if you
are a large company and you have a lot of employee data. The more volume
there is the more controls need to be in place. Greater accessibility
requires stronger controls. So if it's accessible to multiple
organizations, so for example, you have partners and you offer a network
that allows access to information, centralized information, then that
would be a problem right? That would be a risk and the controls need to be
cognizant of those risks. If you have a large number of users,
particularly if you offer the service to the Internet, that again raises
your risk.

So the more risk the more controls. So you need to document a method. Now
I'm going to get into some recommendations here, but you need to document a
method, similar to the one that I just described in a very brief manner,
how you actually assess you're risk and your method needs to be repeatable.
It doesn't say that much about it in the regulation that it needs to be
repeatable. But take it from me you need a formal risk assessment
methodology that you can teach the people inside your organization to do,
to conduct, and then that they can do with a reasonably same similar
results every time. Smaller simpler environments, you document the really
simple process. In fact, if you look at Medicare and Medicaid there's an
introduction, I didn't write it down in here, but there's an introduction
to risk assessment that goes along with HIPAA. It's a really brief like a
couple page document that talks about what risk assessment is. So that's
probably the simplest method of risk assessment. On the other hand, if you
have more complex and high risk environments you might want to go with a
more in depth risk assessment process and methodology and you can look at
NIST standards for that. You can look at ISO standards for that, and you
can also look at OCTAVE out of the Carnegie Mellon, which has a couple of
different versions of risk assessment methodologies. And then make sure
that you document the results of your risk assessments, again this will be
helpful in justifying any controls that you don't implement. So that if you
found that the risk was acceptable and it met the intent of the regulation,
you could use that as the justification that you didn't implement certain
controls.

So as far as partner management. If you share data with any partners or
outsiders you must implement the program, to assess their practices. At a
minimum, look for a description of their practices and that's a really
useful document. A very short document that will that you can had off to a
partner, that doesn't describe the details of your security program, but it
describes the high level points of the contents of your security program,
that you can hand to a prospective customer or partner. So that's a good
thing to look for from your partners.

Document whatever the assessment method that you use to look at a partner's
practices, document that, have an audit trail to show that in fact, you
were in complete compliance with this regulation. So just doing it isn't
enough. You want to make sure that you can point to and say "see auditor or
you see lawyer," during some litigation, "I actually did assessments of my
partners and the fact that they were negligent and allowed a breach to
occur was not my responsibility. They represented themselves as being
compliant with the regulation implementing the controls, as far as my
assessment went."

What you want to do, and I said this at the beginning, create a living
information security program. You want to review your risk and your partner
practices annually. The fact is that everything changes every year, I mean
all the time I should say. The business practice of partners change. So for
example, they might of been offering only the service that you consume
today last year, and this year they may have expanded to offer for many
many different services. They may change their internal technology, the way
that they implement the service that they're providing. And if you haven't
stipulated in the contract you have with them that they have to acknowledge
or they have to notify you that they've changed the content of their
environment and the implementation of the service, then they're not going
to tell you. We've seen this. We've gone out and done these assessments of
partners for financial institutions gone off and said and done another
assessment because the organization was changing the services that they
consumed and found out that the entire infrastructure had changed under the
covers, we had no idea. It turns out they did a great job with security,
but we had no idea that they had changed anything. You want to make sure
that your revisit your partners regularly.

Establish contracts requiring those controls and compliance specifically
with 201 CRM 17, and you want to write this whole thing up as policy. So
you have to have this in place and again, what do you have to do to comply
with this regulation? Everybody has to make sure that they manage their
partners. The depth to which you do these assessments is going to be up to
you and has to meet your risk profile. Identity and access management. Now
smaller organizations should have a relatively easy time with this, because
there are only a few people inside the company who would have access to the
information. But the point is that everybody has to handle the
administrative aspects of the regulation. So you need to establish a policy
that specifies that only a small set of people, who have real business
justification are allowed access to the protected information. Larger
companies will need much more involved controls. That means that you have a
whole work flow in place to say how requests are generated, how approvals
are generated, and how access is actually provisioned for users and how re-
certification takes place. So you want to make sure that you have a process
and you can say why it is, and how it is that somebody got access to the
information. Everyone needs to have a well defined process for removing
rights upon termination. So no matter who you are no matter what size you
are, the regulation specifies you better, especially when someone is
leaving the company, make sure they no longer have any access to any of the
protected information and then use technical controls to enforce access
control unique log ins permission strong passwords etc. Then you want to
log access to the information so you can say who had access to the
information when if in fact you're ever audited or you're sued.

Incident management. Everybody needs a procedure, so there is no way to get
around this either. So you better know what you're going to do. In fact,
it's just the best practice to know what you're going to do in advance of
an incident occurring. We've worked with lot's of companies over the years
we've been around since 1994 and we've gotten called into some pretty high
visibility break ins. In fact one of them was eBay years ago and that was
in the newspaper ,so I can talk about it But the fact is that if you don't
have a procedure and know who how your going to communicate internally, and
what you're going to do when you think you've had when an incident is
occurring you're going to run around like chickens with your head cut off.
It is not a pretty thing. So, just prudence dictates that you should have
those an incident management practice procedure in place.

Simpler environments may have a very simple policy call the IT person and
the President and do the right thing. Eventually all incident management
policies and procedures should have, in the fullness of time, a form for
reporting an incident, a suspected incident, a decision tree for matching
response to the severity, and how you're going to communicate. A contact
list for communicating these issues during the incident response. External
contacts for security expertise that you bring in and make sure that's
coordinated, so you're not bringing in three different consultants to
consult on the same incident. And law enforcement. Making sure that you
have contacts for law enforcement who you're going to contact when you
suspect a breach has occurred and then requirement for post incident root
cause analysis. How did this happen? Why did it happen? And what can we do
better later on? Training and awareness. The regulation requires you to
have a training program. Having a policy is absolutely useless if you don't
tell the employees what they're supposed to do, how they're supposed to do
it, and that they know what they're responsibilities are. So you distribute
your policy and get acknowledgement that they understand what the contents
are. Ensure that employees know and understand what they're
responsibilities are, establish a disciplinary process, that's part of the
regulation. That if someone breaks a policy or is in breach of a policy
that there's actually a disciplinary process in place. Have them trained on
the suspected breach situation, and what they're role is going to be in
responding. Reinforce the need for physical controls. Employees are
responsible for making sure those locks on the doors and the cabinets are
actually implemented, and make sure that employees understand the portable
device requirements and the encryption over the public networks. So making
sure people know how to comply, what the intent is and what they're
responsibilities are to help the organization to comply.

Another one is vulnerability management. Everybody needs to have virus
protection in place. Luckily that's a relatively simple thing to do these
days. It's more difficult however, to do patch management appropriately.
Particularly for smaller organizations. What you want to do is you want to
have a risk assessment in place to understand when it's appropriate to
deploy a patch and when it isn't. Because sometimes you deploy a patch and
it breaks your software. So you're going to have to justify why a patch
that may give rise to a vulnerability, was not deployed. If you don't keep
good records on that you're not going to be able to get through it if you
were sued or someone pursued you in the event of a breach.

So more complex environments are going to require you to do a good job with
network management application vulnerability management, particularly if
you implement your own applications configuration management. Making sure
that all the defaults are being removed from all the systems, which is a
requirement in the regulation, and making sure that you do testing. So
Massachuettes is no where near as perscriptive as PCI DSS but PCI DSS
actually says exactly what you need to do for all your network management
application testing etc. So luckily for us we don't have to it doesn't
prescribe every single event and multiple tests that have to be run for
year per year. Encryption is relatively straight forward. It may not be
easy, it may not be feasible in certain cases. But the fact is that you
have to encrypt your data as it moves on public networks you should WPA2 if
you can, but they can't make you change your encryption,all your all your
wireless devices. So the point is you're going to have to decide if in fact
the protocol that you're using is vulnerable and you've done a risk
assessment you may decide that you're going to encrypt all the data, before
it's transmitted on network that is not protected adequately. Avoid data on
portable devices if you can, use file encryption system on laptops at a
minimum. I'd recommend other controls in fact encrypting, say parts of the
file system or volumes with other mechanisms. But you're compliant with the
regulation if you encrypt your file system. Write down the encryption
policies and make sure the employees understand what encryption
requirements there are. So just to summarize, your approach and the
controls you implement need to match your risk. That means that you're
going to have to write up a policy that says what controls you're going to
implement, and then you're going to capture how those controls match to the
risk. So for smaller organizations it may mean that you don't have to
implement very many controls, and in fact your policy might only be five or
six pages long. I've actually seen some on the web that are very very
brief, and they're written specifically to deal with the requirements of
201 CMR 17. On the other hand, more general security policies tend to be
tomes that tend to be very thick and that may be appropriate for your
organization it may be something in the middle.

If you want to see how to implement certain controls that are required in
here, and that there isn't enough specificity in 201 CMR 17 you can look
PCI DSS as suggested controls. Because the specificity of those controls is
much greater in PCI DSS than it is in 201 CMR 17. Now let me just clear
something up. So are you compliant with 201 CMR 17 if you implement PCI DSS
controls? The answer to that would be no. Why? Because PCI DSS only deals
with your card holder data environment and card holder data, there's lots
of other data that might be floating around your environment. However if
you implemented PCI DSS controls for everyone of the data specified under
the Massachusetts regulation you'd be flying, you'd be great. Unfortunately
nobody wants to do that because PCI DSS is such a pain. So just to clear
up, just in case there was any confusion about that. So the key to doing
this job is to establish a minimum program with periodic check and
refinement over time. So don't hold back implementing the security program
because you don't think you can do the whole program at once. Get the
controls in place that are most meaningful and reduce the most risk for
your organization. That's going to allow you to achieve your security goals
first. Now another point that you should remember is, you're best control
your best cost control in fact, is going to be to isolate the information
as much as possible and eliminate any data that you can. So if you can get
rid of this data you're in way way better shape.

So if your business can do without some of the identity data that is
covered under this regulation get rid of it. In fact one of the things that
we do when we deal with companies that are trying to deal with the PCI DSS,
even though we're qualified security assesors, one of the recommendations
that we make is why don't you just out source the whole credit card thing,
just don't deal with that data anymore. That way we don't have to do an
assessment we'll get paid to tell you how to comply if you need to comply,
but you'll reduce the headache of compliance substantially. So get rid of
the data if you can isolate it so that the controls only need to be applied
in a very very small environment. Then you'll cut your cost of
implementation substantially. And then lastly I already said this, but it's
worth saying again, is establish your security first. Make sure you protect
the data if you protect the data you're not going to have a breach or you
lower the likelihood of a breach, and then you can deal with compliance in
your own sweet time. Thank you very much.

 

More on Data Privacy and Protection

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: