Crafting a Nonprofit IT Security Policy

Community IT CEO Johan Hammerstrom has a conversation with cybersecurity expert and Community IT CTO Matt Eshleman about what policies you need, and where to find templates for them. 

Do you have the security and IT general policies you need? Have they been updated recently to reflect any new work environment or expectations? Are staff using personal devices? Are they working from home? Are you requiring MFA on all log ins, or using Single Sign On? What do you do when staff off-board to recover company data assets and reset their passwords? 

Crafting nonprofit IT security policies helps your teams think about your IT expectations, and helps clarify expectations with staff.

_______________________________
Start a conversation :)

• Register to attend a webinar in real time, and find all past transcripts at https://communityit.com/webinars/
• email Carolyn at cwoodard@communityit.com
• on LinkedIn

Thanks for listening.

Transcript

Crafting a Nonprofit IT Security Policy 

July, 2017

Johan Hammerstrom:  Welcome to the July (2017) Community IT Innovators Webinar.  

Thank you for joining us for today’s webinar on Crafting Nonprofit Security Policy. This webinar is a complete refresh of one of our most popular webinars of all time on IT Security Policy from just over two years ago. Good afternoon. My name is Johan Hammerstone. And I am the president and CEO of Community IT and the moderator for this series. 

Before we begin, I'd like to tell you a little bit more about our company; Community IT is a 100% employee owned company. Our team of almost 40 staff is dedicated to helping nonprofit organizations advance their missions, through the effective use of technology. We are technology experts, and were recently named again, a top Washington DC- based managed services provider for the third year in a row by MSP Mentor. 

And now it's my pleasure to welcome today's presenter and our Chief Technology Officer at Community IT, Matthew Eshelman. Hi, Matt.

Matthew Eshleman:  Hi, thanks for the intro, Johan. Yeah, it's good to see that recognition continue again from MSP Mentor. And, again, good to be in the top MSPs based here in DC. I know I just actually looked at my calendar; I actually started as an intern at Community IT 17 years ago, on Monday. So it's been great to be a part of this company and to be an employee/owner. 

So looking forward to today's topic, and before we really jump into it, I did want to provide this list of resources for some  background reading. 

So we'll start at the top. At the beginning of last year, we co-sponsored the Idealware Security Report. And that's a great resource.

We have also developed our own Community IT Security Playbook, which is available as a download from our website. And we've done a number of security focused webinars and so this is really building on some of the previous webinars that we have done. So this webinar and all previous webinars are available on our YouTube channel. And also available on our SlideShare page. 

If you are late attending or if you're not going to stay for the whole thing, don't worry, you will get a copy of the webinar and slide deck pretty soon after the session is completed. 

And then, I've added an additional link here, since we're talking about IT Security Policy, I want to provide a reference link to a really great resource from SANS and their security policy templates.

So this is a resource that is free and publicly available and can be a great place to look to start. 

So if you're looking to get started with an IT Policy, we are looking to make sure that you have all of your bases covered. This is a really great resource for getting ideas for those policy templates and building from there. 

This graphic is taken from our IT Playbook that talks about our comprehensive view, our holistic view of how Community IT thinks of security. 

We've got 

• predictive intelligence on the top, 
• we've got overtop passwords and antivirus and backups and patching. 
• That's on security, training and awareness.  
• And then down at the bottom, we have the foundation, which is written and updated policies. 

So, it is a little bit interesting that we're now doing this webinar on written and updated and developing a policy, which is on the heels of some more specific topics that we've focused on. Single sign on, security breaches and some other things. We did want to make sure that we were looping back.  As Johan mentioned, we did a security policy webinar about two years ago. And so this is an update on that. And I think if you have watched that webinar, and then compare it to this one, I think, there's certainly an evolutionary change in how we're now seeing and thinking about IT security policies.

So as we go along, we have a great list of questions that folks have submitted ahead of time.  Please feel free to chat in questions and Johan will be monitoring that and interjecting as applicable. And if not, we will answer questions at the end. 

So, we're together for about an hour today and attempt to make the best use of our time.

Terminology

Just some basic terminology:

We're talking about policies and again, those policies are the principles rules and guidelines formulated or adopted by an organization to reach its long term goals. 

So that's the framework that we're talking about today.

Guidelines, they’re recommended practices, get some discretion, some leeway, like, hey, these are some good ideas. These are the guardrails.

We have standards, which would be universally accepted or established meanings. So, we may say, Hey, we're going to use the AES-128 Encryption Standard as something that we are going to mandate as part of our communication. So that would be a standard. 

Then we've got procedures that really talk about how all these things get put into place, how we really take the policies and put them into action. 

It's always good to start with a little bit of background, just terminology, so that we're all on the same page in terms of definitions as we move forward.

Security Policies

There were a number of questions that were asked ahead of time about 

what policies to have and where to start, and there's a couple of items on here: 

• acceptable use policy, 
• data policy, and 
• identity account policy, and then 
• HIPAA. 

Acceptable Use Policy

As we have seen organizations operate in action and be exposed to different security threats. 

I think this follows what I see as the biggest priorities in terms of what organizations need to focus on.  

Often, the acceptable use policy is something that most organizations already have that's typically part of your employee handbook.  It oftentimes describes  good computer behavior. Don't look at websites you're not supposed to, your computer is to be used for business purposes, there may be things like, you don't have an expectation of privacy, or monitoring, the IT Department has the ability to monitor things, and so forth.

So I think the acceptable use policy is often a great place to start.  If you don't have anything, that's probably where you should start. 

If you are an organization  looking to build out, the acceptable use policy provides a framework or a way to insert or add additional policies into something that already exists. So again, I mentioned, the acceptable use policy will often describe how to handle computer equipment, what's provided, it will govern  examples of what web browsing is acceptable. 

It can also be a place where things like your mobile device policy can be included as well. So how are mobile devices handled? A BYOD approach where staff can bring their own devices and connect them to work resources, is that permitted? Are employees provided with business resources and how is that line drawn?

One of the things that often comes up is, how do you handle reimbursements for that?

I know, in the past couple years, Community IT has  changed how we handle that because of some IRS guidelines. 

So we now provide a technology stipend and it's just provided to all employees. And that's a taxable benefit that we get, because the other alternative would be for employees to get reimbursed for the portion of the phone that they use for business purposes and that becomes an administrative headache. So as a policy, we've chosen to go that route.

I do think in the nonprofit space, in particular, the pendulum is swinging back a little bit from being really permissive about mobile devices, where “Hey, Staff! Isn't it great that you can use your phone to get your email?” to a position where people are being a little bit more thoughtful about what it means to have company data on personal assets.

And I think because the technology has also improved, so that it's a little bit easier to implement a mobile device management policy where there are more tight controls over what data is allowed on phones.  Have the ability for that phone to be wiped if it's lost or if an employee is off boarded and so on and so forth. So I think, Mobile Device Policy, I would put on there, as a higher priority policy to have and can be nested under that acceptable use policy.

Data Policy

The second bullet point is around a data policy. 

And this is a fairly broad topic. And it's  broad intentionally, because as we've seen more and more information go to the cloud.  The cloud doesn't necessarily change things in terms of not needing to think about it or not needing to have a policy, but it  opens up more opportunities for questions to be asked.  The data is no longer in the server closet down the hall, so we don't really have data residency issues.  It could be on the web somewhere. 

So it presents more opportunities for questions around how data should be managed, what controls we want to have around, what expectations we have of our vendors, what other  information we need to layer on so we understand our data.  Not just file data, but also database systems, digital assets, like pictures.  Think about data broadly, as opposed to just where my file is stored, where my email is stored, because that data can be stored in lots and lots of different systems, not just systems that deal with storing discrete files.

Identity and Account Policy

I have identity and account policy as a separate line item as well. This becomes a lot more important because we were talking about identity, not just your Active Directory account, you use to login to your computer, but we're talking about your identity that is now used to log into Salesforce, to Hootsuite, to Twitter, to your HR system online. 

So this identity now exists and travels with you, not just within the bounds of the network, but across the whole cloud and web application sphere, where you are accessing systems, many different systems. And so each of those systems  creates an opportunity or a window for data loss to occur, for systems to be compromised.

Having a clear sense of what expectations are around managing an identity, what security policies we want to apply can help focus an organization on thinking about that much more broadly than  a single account.

HIPAA

And then finally, I do have HIPAA on here, there were some questions around, “What compliance rules am I required to follow as an organization?” 

I would say, typically, nonprofit organizations may not have many “legally mandated compliance requirements” that they need to follow.  The big exception would be HIPAA and PCI compliance. 

And so, fortunately, nonprofits don't have the same overhead required for certain mandated security controls that other organizations do. In a lot of ways, nonprofits are certainly leading edge when it comes to Cloud Adoption. But at the same time, I think nonprofits are way behind the curve when it comes to security. 

I had the opportunity to attend the RSA conference in San Francisco back in February. And the other attendees were all Chief Information Security Officers and other people whose job it was entirely to work on security. And whenever the topic came around of who's concerned about data security - losing a laptop? Nobody was concerned about it. Who's concerned about a user password being compromised? Nobody's concerned about it. 

And it wasn't that they weren’t concerned about that specific activity happening.

They weren't concerned because they had compensating controls in place. So nobody's concerned about losing the laptop, because they had already implemented encryption. And that was a universal standard.  They weren't concerned about somebody's password getting compromised, because they had already implemented two factor authentication as a requirement and they've done that in response to a lot of regulation and compliance requirements. 

And that same standard typically does not apply for most nonprofit organizations. So it is hard to implement some of these  stronger security controls because there isn't a mandate to do so. And so, while we'd hope organizations are taking a more proactive stance, in terms of improving organization security, it can be a challenge if there's no stick to force that compliance.

CIA Inventory

(14:23) I talked a little bit about the data privacy in the previous slide. And one way that we often think about that is doing things through a CIA framework or a confidentiality and integrity and availability framework.

Categorize data and help provide a rigorous classification, where information should be stored and what other controls may need to be placed around it. 

We see we've got some things that are sensitive data like medical records and then we can categorize those saying medical records have a high level or high degree of confidentiality, a high degree of integrity, and a high degree of availability. And we can create IT systems that can support that requirement.

Whereas program management, maybe that's a low degree of confidentiality, a moderate degree of integrity, and a moderate degree of availability. And as a result, different IT systems can be put in place to support that framework. 

And again, as much as we're talking about developing IT Policy that really should come first.

So as opposed to thinking of the technology and then working backwards, it's preferred to think about the policy and the data first and then find technology solutions to meet those organizational requirements. 

In our previous webinar, we talked a lot more about the CIA triad and some different ways to view data from that perspective. So I think it is a helpful tool and I did want to include it as part of this presentation as a way to provide a framework for thinking about the data and the systems that these policies are going to be applied to.

IT Security Policy Process

(16:21) So in terms of implementing an IT Security Policy, this is something that needs to follow a fairly well defined process. 

And it's a process that really needs to start with senior management, “the board level support or mandate,” and this is an important distinction to make.  

IT policies developed by IT for IT, I think are often not very effective. They can be viewed across the organization as a land grab or a control grab by the IT department and  unnecessary. 

So I think our position would be that these IT policies really benefit having executive or board level sponsorship to ensure that they are supporting the broader organizational goals.

And again, that's what the IT policy is for - to really support the organization itself, as it works to achieve its mission.  It's not in service just to the IT department. 

So, once the senior management or the board is  engaged in that process, then the process can begin to develop a draft policy. 

And, as I mentioned, there are a lot of great templates and resources out there.  The SANS ones, I think, are very good and thorough and well written. But it will say a lot of the policy templates out there are big.  I mean, they're big and maybe excessively comprehensive for nonprofits. And so I think they're a good reference point, I think organizations would be much better off to  look at those, consult with those, but instead develop their policy, in house, from the ground up, as opposed to adopting an existing policy template and working from there.

I do think the nonprofit culture and work style/work habits is different than the enterprise where a lot of these templates come from, and so you'd be much better off starting from scratch to talk through what's important for your organization and then maybe do a cross check with some of these larger, more elaborate policies to make sure that you're not missing things, but starting organically, as opposed to shoehorning a big policy to fit your organization. 

In terms of overall process, flowing from that draft policy, then that can go to colleague support or program support. 

For example, if there's going to be some data management or data retention policies that may need to have support from other folks in the organization, to say, “Hey, we're concerned about, we've got files on our file server that are 20 years old. And we think we can have a data retention policy that says, hey, after a program is over, we only need to keep it for seven years.”

And so, enlisting the colleagues to  refine and create those policies is going to go a long way into the overall success and adoption of the policies in general. 

So once the supporter thing has been enlisted for these policies, then we can move into, “Okay, how are we going to monitor these things?”

And I think this is another area where smaller organizations with not as many resources find it hard to really rigorously monitor a lot of these policies and systems over time. I think that's why organizations are better off being a little bit more general, in terms of their definitions, and try to anticipate how much time it is going to take to effectively monitor and manage these policies once they have been implemented.

Some guidance could be, start small and work from there, as opposed to defining a very rigorous and extensive policy that's going to require a lot of management and overhead to deal with in support. 

And then finally, once we have some boundaries around how we are going to monitor these policies, then you can move into an implementation phase. And we'll talk a little bit more about some different approaches for implementation as we move along.

Important Considerations

So again, as I mentioned, you know, we have some important considerations to think about as policies are being developed. And I think, coming back to this first concept of policies requiring executive support, this should not be a bottom up approach.

This is one area where it is important to have a top down approach to policy development. And again, starting with the policy first.  

It is really interesting to see all the new and amazing stuff that a lot of these cloud solutions can do in terms of applying policy tags and retention tools and all the features that are available out there.  But it's important that the technology that you're using now does not drive the policy decisions that your organization is making. The decisions that are being made around IT policy are not technology.  They're not first and foremost technology solutions. They are organizational policy decisions and then you can find the appropriate technology to meet and support those requirements. 

Determine level of investment to meet policy requirements.  I think this is another area where I see the nonprofit sector being a bit behind the for profit world, because there's often not a compliance or need to do that.  You don't need to spend money on these e-mail retention systems or data mining solutions.

And so organizations don't make those choices. So, it is important to understand the level of investment required.  If an organization is saying, “Hey, we're going to keep all of our data for all time,” or “we want to have a very sophisticated classification system to keep program emails for five years, but legal e-mails for seven years, and we're going to keep other email for a year and we're going to have all these overhead and requirements for data that we manage.”

The other thing I think that's important to note, and it struck me especially looking at our webinar from a few years ago is to recognize IT policy are living documents.   A lot has changed in a year, and the policy that was relevant for IT a handful of years ago, may not be relevant anymore. There are references to technology that's no longer used or maybe IT systems that are no longer needed.

Your organization's data may have moved two or three systems from the original reason for the policy. And so I think it's important to be able to recognize and have a process or system in place for an annual review checkup. Even if it's not going to be a total rewrite. But just a course correction to determine if the IT policies that are in place are still meeting the current recommendations and best practices.

We see evolving security best practices, in terms of how we think about putting a good balance of security at our organizations. Balance overhead with hassle in terms of the implementation. 

We already talked about a fair amount starting from scratch or starting from a template. There are a lot of great templates. But I think again, if you do have the time, starting from scratch is going to give you a better and more tailored solution for your organization as opposed to something you're shoehorning. 

We've talked about developing a monitoring strategy and then finally ongoing training.

IT security requires constant vigilance. Ongoing training is something that I think needs to be a much more proactive and interactive approach than just the official employee handbook that sits on the shelf that reminds people to not go to websites that they shouldn't, that aren't required for their work. 

The good news is that there are a number of good online training resources that are available that can help to support and supplement your IT security policy, particularly when it comes to good password policies, good safe web browsing habits and other aspects of good end user behavior.

Ongoing training really needs to be thought of as the policies are being developed. And it needs to be something that is envisioned to be interactive, rather than stuck in the employee handbook that doesn't get read beyond the first week of the job as somebody is getting on-boarded.

Organizational Adoption

So once we've gone through this process and we get to the organizational adoption, there still are a few more decisions to be made in terms of determining the implementation approach.  If you're going to do a big bang, like, “Hey, we're implementing a new IT policy, and that means, X, Y, and Z.” So is that something that's going to happen all at once? Or is that something that's going to be more of a phased deployment approach? 

The good guidance around this, particularly from SANS, is to say, “Hey, you've worked really hard on your IT policy and we want to go ahead and just implement it,” and implement it all at one time. We have one end user impacting event and we can work through that as opposed to a slow and steady drip of maybe behavioral changes that staff need to be made. Again, I think this is going to be driven largely by an organization's culture, in terms of what's going to make the most sense. 

And so you know, as much as you can, I do think this big bang approach is probably preferable, particularly if it's going to involve a lot of user change. So it's good to have a build up in focus on training around that influence your policy.  Mostly we're talking about things that will impact end users potentially, like password changes, password policies, maybe changes to your mobile device management approach.

These are things that you're probably well served by doing it all at once, after a small deployment or a small pilot group to make sure that everything is working effectively and then you can go to a broader deployment. 

It's important to have a realistic date; it's not something you want to rush. And it's not something you want to drag out and never have an implementation timeline. So set a realistic date for that adoption and move forward whenever time comes.  

Obviously, there’s going to be some issues, nothing’s going to be perfect. There may be situations that weren't anticipated during the creation of the policy and it's okay. 

But it's important to acknowledge that there’s going to be some challenges to planned work. Include that feedback, maybe modifying the policy and then moving on from there.

Our Approach to Policies

(28:11) So it's specifically our approach policies,  I’ll  share how we think about things and appreciate any comments or feedback folks have. I would say, in general, our approach to policies is generally permissive. So if you look at some documentation, there's  a couple different levels. There's areas where anything goes, you do whatever you want. 

There's permissive, which generally is to allow things.  

There's conservative where the default is to deny things. 

And then there's really restrictive and so that would be when you can't do anything except with approval. So that may be more appropriate for the military or NSA or whatever. 

In general, we find that a generally permissive organizational policy suits the nonprofit culture best, because we  trust the staff that work in our organizations. And we aren't going to invest as much in the overhead apparatus to really monitor and manage a more restrictive policy.

So, again, while our 

• default is generally to allow behaviors, 
• we do typically say no administrative access - for staff, for end users, they should not be administrators on their computer. 
• We would require good passwords and multi factor authentication. So the multi factor, again, this represents an evolution in our thinking of security policy and saying, Yeah, good passwords are great, but use multifactor. Now I think through the advent of the cloud, and a lot of these services moving to the cloud, multi factor becomes a lot easier to implement and to manage and to enforce and so this is a great security improvement that we can take advantage of and want to do that.
• We want to encourage security awareness because we're not investing in really sophisticated technology solutions to protect users and  protect users from themselves, we want to make sure that users are empowered to  make good technology solutions. So we have a security awareness training tool that we use internally. And I think it's good to  keep repeating and lifting up security as a topic that we all need to be aware of and  each individual has a big impact on the overall security of the organization. 
• There's some other basic things like, we're going to require antivirus, we still think it's a good idea. We actually have sophisticated predictive intelligence, we use that top layer.  That may not be within reach for every organization. But that's a solution that could be implemented as well. 
• We're requiring weekly patching which means you have to reboot your computer every week.  That might be something that's a challenge at your organization, just to tell people, “Yes, you're going to have to save all those 15 documents that you have on your desktop,” you get to close your computer, your computer's going to be rebooted once a week. We know security patches are effective. And that's how these vulnerabilities are being spread. And so we need to be really proactive about patching. 
• Backups for everything. I think this is an area where the cloud has made this a little bit more challenging.  It can seem like it's out of sight, out of mind. My data is in a cloud, I don't have to worry about it anymore. But again,  coming back to your policy, if you have a good policy in place that says, “Hey, we need to have data in a system that we manage, that we control, that we have access to all the time,” then that would mean that you wouldn't have your data in just one cloud system because if there's an issue with a vendor, the data got corrupted somehow, some other issue. That could be a real problem, if the approach the organization was completely trusting their cloud infrastructure provider.

So maybe backing up to another cloud may have some other redundancy. But again, I think that's an example of where your policy can really help to inform some of the behaviors, the technology solutions to support those services that you're using. 

• We're going to monitor and audit logins.  This is another thing that the cloud really provides. If you're back in the old days of on premises file servers, unless your organization has invested in some really sophisticated technology tools, it's very hard to say, “Oh, I know, Johan accessed this file on this date, from this computer,” It's just very, very difficult to do. But now, through a lot of cloud based services, it's really easy to say, “Oh, I see Johan accessed the webinar planning document three days ago and made some changes.” Moving to cloud services makes the auditing or reporting for the services a lot easier.  And so it's easy to keep tabs on things to know when things look funny or going wrong. 
• And I would say the other thing to that is, we're not typically monitoring web browsing. And again, I think this is also a good expectation to be setting for clients, and for the organizations about understanding your IT policy and understanding how it's being implemented. We do often have situations where organizations will come to us to be like, “Oh, I need to know what Bob was doing on the web five days ago.”  And the short answer is that we don't monitor web traffic and you don't have the technology tool in place to support that. So if monitoring web traffic is important to your organization, it's important to have a technology that supports that policy. So in general, we're not doing that. There are a lot of technology solutions that will meet that requirement. But  by default, that's not something that we find is as valuable as focusing on some of these other areas. 
• And, again,  the final concept here, it really is a concept is that we're typically following a defense in depth approach, as opposed to a [Inaudible] [0:34:27]. Whether you're in an office that could be you've got your firewall, you've got your segmented network, you've got no administrative permission, you've got web filtering, you've got spam filtering. So that's  an example of defense in depth saying if the web filter doesn't get it, the desktop antivirus might protect you.  So that's  a defense in depth model. 
• And I would say we are moving towards a little bit more of an assume breach mentality where we're going to set up and design systems that assume that maybe an attacker is already in the network. And so if you're in that mentality, then it means you're relying a lot more on encryption. So that even if somebody has access to your computer, they can't actually see or manage to get access to any data. Because that data is all encrypted and that encryption key is  only available to the  known and approved end user.

That's  the guiding policy that is helping to inform how we are implementing these IT policies. 

I think it is interesting to see particularly how other organizations, organizations that think a lot about security, talk about this stuff. 

This is Microsoft Cyber Security and Defense Strategy. This is their stated policy document framework that they use for thinking about IT security at Microsoft. So, I think it is very interesting they've got these three top level things about investing in your platform, investing in your instrumentation and investing in your people, and talking about all the different areas that require focus.

So I think the things to highlight and I think the things that are relevant in our space for whatever 10, 15, 20, 50, 100-person organizations are in terms of investing in your platform, talking about maintaining a well documented inventory of your assets. So knowing where does data live in your organization? What's important to us with sensitive data and having that documented ahead of time, so that you can apply policies to that data.  

Most attacks could be prevented with timely patches and antivirus. And again, we're seeing this  over and over again, where unpatched systems or out of maintenance systems are compromised.  And then again, here, employ multi factor authentication to strengthen protection of accounts and devices. 

And this is something that we've started to recommend and implement more and more is multi factor authentication as part of that identity account management policy.  We want to ensure that there's a good password in place.  We want to ensure that that password is protected by multi factor authentication. 

If you have attended some of our previous webinars on security, we are seeing many examples of account compromise through a number of different attacks through spear phishing attacks, through general brute force attacks, both through web based, Office 365 applications or attacks against terminal servers, stolen credentials, we're seeing the whole gamut of it.

Our reaction has been, “Oh well, if two factor had been in place, we wouldn't have had the security issue to begin with.” So, again, good patching, good password policy, good account hygiene, multi factor authentication, these are all really important steps to take.

It does require more from the end user, you can't just type in your same five character password that you've had since 2003. But, the organization overall is going to be in a much better state from a security perspective.

So it's worth that trade off, to make those changes. And again, I would say, that's another reason why coming back to this IT Policy Development workflow, it really does need to come from the top. So, if the board or the executive director is saying, “Hey, we really need to make security a priority and as a result, it's important for this organization that everybody has a good password and two factor authentication,” that's going to go a lot farther than the IT guy or the IT person or the IT consultant coming in to be like, “Oh, hey, you really need to have a better password policy.”  The adoption just isn't as good.

I think this middle column: invest in your instrumentation. Again, because I would say, in general, our approach is rather permissive. It's an acknowledgment that the instrumentation is pretty expensive, even now if you are in Office 365, if you're in the G3 cloud, you're already seeing some of the benefits that moving to the cloud gets you in terms of some more specific kidded analysis.  You may get a notification, “Hey, we think your account has been logged into from another location that doesn't make sense.  We've blocked it, here's how to get back in.” Those are all benefits to take advantage of.

But if you're still living in a largely unframed world, it's really hard to add that level of sophistication. So it's a note on the instrumentation.

Invest in your people, and I think the thing you need to highlight here, again, least privileged administrative access.  We don't want to have folks with local administrative access, even if it means they have to go through an extra step to install software. It creates a much more secure environment. 

And again, something that we try to do here is using lessons learned to gain value from every major incident.

So whenever we encounter a security incident at one of our clients, our incident response policy basically involves review as part of that response. And then we turn that feedback around to  share with the rest of our organization. And maybe make it available in newsletters or other things, so that we can help to learn from those scenarios and hopefully prevent that and maybe other scenarios from reoccurring in the future. 

And again, educate, empower, and enlist users, as a way to protect business data.  There's this  new concept or newer concept called the human firewall.  Each individual person is their own good firewall.  As many security tools and policies you have in place, if they're going to click on that link that comes through, or if they're browsing to websites that have a bunch of malware in it, it's really hard to protect against everything all the time. So as much as we can empower and educate our users about good security practices and good computer hygiene, the better off that we're going to be overall.

Where to Invest

As we  come to the tail end of the presentation,  talking about where to invest, this can be really daunting, especially if you're an organization that's just getting started.  You don't really have much to go on.  Where do you focus?

And I would say there's probably three things to focus on. 

• So one is just starting with that Acceptable Use Policy.  In general, you may already have something similar to this or the beginning of this in your employee handbook. So that's a great place to build on. And that can be used really as a framework to link to and incorporate other policies into the organization.

• The next thing that I have is actually, it's not the passwords, but it's a clear backup and data retention policy. And the reason I have this second is because our first reaction whenever there's a security vulnerability or security breaches, often data has been lost or compromised in some sort. And so, if an organization hasn't had a well defined or well articulated data retention or data management policy, it can be very difficult to  recover from that. So something happens, somebody's email contacts are lost or deleted. Well, if we haven't defined that organizational contacts are really a critical resource, we need to make sure that it's backed up. 

If that's only discovered after the data has been lost, then that's a really hard thing to recover from. So I think, understanding your organization's data and having a clear articulation of what's important: where does it reside? how are we protecting it?  is really the next step that organizations need to take.  

• Once that's been defined, then I think, certainly, we can move on to having a strong identity and account policy that really governs the policies around passwords and single sign on, account access.  Those are good things to have, too.

And so these, I would say, would be the first three things to focus on. 

Aligning the technology with policy, these are all decisions where the policy comes first. And you can find technology and technology solutions to help support those policies that have already been defined. So again, acceptable use policy, talk about things in general.  

We find that these acceptable use policies say things like, “computers are for organizational use, they're not for personal use. And there's no expectation of privacy, we want to encourage good computer stewardship.” This acceptable use policy is really an umbrella policy that can help reference other policies and so that can be your framework that you can build off of.

Again, the data policy we're talking about data, a big, big D data, data in wherever it may reside. And so that may be your email blast system, it may be your CRM, but the  data broadly where does that exist? It's not just files anymore. 

And use that data classification, the CIA triad to help provide some additional perspective on that. Is all data super confidential? High degree of integrity, always has to be up? Yeah, maybe so. So let's find technology solutions that can help meet those requirements. And again, define the retention requirements. This one I think is tough. Storage is cheap, the time to figure out what data we need to keep around, that requires a lot of person hours to sort through and figure out.

And so this can be a hard one to say, yeah, we are going to actually go through and purge data that we haven't accessed or used in seven years, and we are going to be pretty assertive about cleaning out our mailboxes, because we're concerned about what happens if that email gets compromised. So data retention can really help drive some of those decisions.

Then finally, identity account policy. The password policy is probably the most contentious of all issues. And, I know we worked with organizations for months and months and months to make a change from having a seven character minimum to an eight character minimum. So I don't want to  undersell how big these changes can be in an organization. 

Password Policy

So this is our current best practice being an eight character password minimum, we want passwords to be changed every 90 days, we want to have account lockouts to help prevent against brute force attacks. And when possible, we want to have 2 factor for cloud based solutions.

Ideally, we're also doing single sign on, we talked about single sign on in a previous webinar, so instead of remembering or using a password manager to remember the 15 to 20 different passwords that you use, you can use a single sign on solution to have a single password. And all these systems are authenticating against that single directory. And that's a secure password with a second factor. And then we can  manage an audit report in one location for all the applications as opposed to needing to do audit reporting against 20 different websites. 

And there are some other things that, I think, have been best practices for a long time. But again, it's just worth reading mentioning, renaming your default admin accounts, having complex service account passwords, so we've certainly seen accounts like copier or scanner with passwords that haven't been changed in years.

And so, being mindful of how those accounts are created and maintained is an important step in this overall identity and account policy. 

Questions?

(47:59) We do have a few minutes for questions. And I want to have some time to answer questions that were chatted in as we went throughout this presentation.

Johan Hammerstrom:  Yeah. Great. Thank you, Matt. That was excellent. One point of clarification, no pun intended, you had mentioned, it's important to have a clear backup and data policy. And I was wondering if you could just elaborate on what you mean by clear.

Matthew Eshleman:  Sure, I think what I mean by clear, is an organization has an accurate understanding of where their data lives. So we have file data, here's where the file data lives. We have email, email data, here's where the email data lives and then have an understanding of if that data was lost or compromised or cryptoed. What do we need? Like, what do we need or what do we expect, maybe is a better word, to be able to get that data back? Do we expect to be able to get all that data back within a couple of hours? Do we expect to be able to recover a file that was deleted five years ago?

Do we expect to be able to recover a certain database, like certain records if they were deleted? And I guess, maybe a specific case I can think of is, if an organization doesn't have a well documented data inventory system, what could happen is the system gets compromised, maybe the server crashes. Okay, we have a backup of this data. Here's the folder, we're going to restore the data in that folder. And then we come to learn that, Oh, well, this user was actually storing data in this other location that wasn't part of the official  “backup system.” 

Often organizations will say, “we're backing up the network data.” And if it's on your computer, it's gone. But I would take that to say, let's just make sure that all the data that's on the network that is assumed to be backed up is, in fact, backed up.

And so again, it's checking those expectations to say, “Here's my expectation. Let's have a conversation with IT. Hey, I expect to be able to recover the deleted file that this person deleted a year ago, can I actually do that?” And so, you can walk through those scenarios to test those assumptions that the technology solution is in fact, living up to your expectations.

Johan Hammerstrom:  So the data policy is a combination of a data asset inventory, combined with availability requirements, recoverability requirements and a specification of the systems that are providing the functionality.

Matthew Eshleman:  Yeah, yeah. I think that's accurate. And I think, the backup and disaster recovery plan, or the business continuity plan will often make reference to some data inventory list. And there might be additional dimensions of data that are added when we talk about the backup and disaster recovery plan. But again, it's important to have that inventory, so that there's a common understanding about what is our organizational data? Where does it live? And then you can go from there, how are we backing up? How are we retaining it? What happens if you lose access to it?

Johan Hammerstrom:  Mm-hmm. Great. Um, we have another question. Actually, there have been a number of questions about templates or samples that can be used. And I think you addressed that pretty well, early on, you know, SANS publishes a guideline. 

But I think really, the most effective policy is going to be one that is consistent with the other policies that an organization already has. And you're better off working within the existing policy framework for your organization. And rather than trying to shoehorn a template, it's in a completely different format. And I think that gets to the adoption policy, adoption process that you outlined earlier in the presentation.

Matthew Eshleman:  Yeah, I mean, I think that's right. I think that the policy templates are great  reference checks to make sure that you're covering all your bases. Yeah, but I would say that, in general, I think the policy templates that are out there are very exhaustive and so you'll probably spend more time throwing out things and you do adding, yeah, adding to it.

Johan Hammerstrom:  Mm-hmm. Um, there are a couple questions about custom built web based systems, website redesigns. To what extent do you see IT security policies extending out to things like websites, social media accounts, things that are maybe not traditionally considered part of the purview of the IT department?

Matthew Eshleman (53:38) :  I do think that coming back to this idea of data, your data policy and that would extend maybe to your data security, I think is relevant particularly when you're working with additional vendors, where you're providing information to. I remember one specific example, where an organization, I think they were using Salesforce as their CRM, like a lot of other organizations and they were looking for a vendor. They were looking for a vendor to do some mailings. So they wanted to give them access to their Salesforce database, generate a bunch of mailings, send it and they found through their contract review process that they had a couple different vendors or two vendors that they were looking at.  One would essentially take a copy of their data and then run all the processes from this copy of the data, and they would  “have it on their network.”

And then the other vendor, essentially would be able to look at the data to run the reports, but they wouldn't actually keep or retain any of that. And so in that case, the organization, because of their data policy said no, we need to keep tight control around our organizational information. And so we can't use a vendor who is going to have a copy of our data on their system, even if it's just to  do work that we say that they can do. So I think that's an example. 

So again, if you're doing a website, you're providing a lot of information to or through this website, vendor or developer.  It's important to understand what are your data boundaries around the information that's being provided? Is it going to leave your control? Is it going to be accessed by an entity that you may not expect to be able to access it that way?

Johan Hammerstrom:  Mm-hmm. Yeah, that's a good, great consideration. I like that concept of data boundaries as a way of thinking about where your data might go, how you want to control it. 

There have been a couple of questions about specific tools, questions about the best type of firewall for home environments, a question about hardware firewalls versus software firewalls, a question about the best antivirus or antimalware package. 

I was wondering if you could just - we only have a few minutes left. But if you could speak broadly about how IT Policy can help inform decisions about types of security solutions or the selection of various security solutions?

Matthew Eshleman:  Sure, I think everybody wants to  make sure they're having the “best technology” to protect their organization. 

I do think it's important to understand that there is no silver bullet, there is no  perfect technology solution that is going to be right all the time. And I think that is one of the really challenging things in IT and IT Security is that, you're playing defense, you're going to have to be right 100% all the time. 

And it's the one unpatched system that can be compromised and bring down the rest of the network. So, that's why I think in general, IT Policy should be rather broad and  non technology specific. 

So, it may be appropriate to say if you're working in the office, we expect to have a firewall that's going to be filtering traffic and we're going to be blocking the known threats. And leave it at that. And then it's  up to  working with it to do a vendor evaluation to say, “What's going to be the best firewall for us right now?” And I think, now probably more than ever, what makes the best firewall, may not be just how it performs technically and blocking threats. But how effective is it at reporting? What's the user interface? How has that experience been?

For us personally, we've started to use Meraki a lot more as a security appliance. And I think it's a good firewall and in terms of its technical capabilities. But the real benefit is that it's really easy to use and administer and we get a lot of insight out of it. And so as opposed to maybe some other solutions, maybe even were more superior technically, understanding how they were working, getting reporting out of that was a lot harder. So being more general, yes, computers need to have antivirus.  Yes, we need to have a firewall, working with trusted partners to find out what's the best solution for your needs, right there. There could be different options depending on other requirements of the organization.

Johan Hammerstrom:  Great. Well, thank you, Matt. We are now at time. So, go ahead and end the webinar. There were a couple more questions that came in, and I'll leave the webinar open for just a second and respond to those through the chat tool, but I want to thank everyone for joining us today. And thank you very much, Matt, for your time. This is a fantastic, very interesting webinar, a great topic. And we intend to publish a little bit more on our blog on this topic. So keep your eyes open for that, and we'll send a link out to that, as well as a link to the recording and slides for today's webinar.

Thank you, everyone. Thanks, Matt. Have a great afternoon.

Matthew Eshleman:  Thank you.