cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Does Compliance Start with Software, or with People and Processes?

Level 11

All too often, federal IT personnel misconstrue software as being able to make their agency compliant with various regulations. It can’t – at least not by itself.

Certainly, software can help you achieve compliance, but it should only be viewed as a component of your efforts. True and complete compliance involves defining, implementing, monitoring, and auditing processes so that they adhere to the parameters that have been set forth within the regulations. First and foremost, compliance requires strategic planning, which depends on people and management skills. Software complements this by being a means to an end.

To illustrate, let’s examine some regulatory examples:

  • Federal Information Security Management Act (FISMA): FISMA’s requirements call for agencies to deploy multifaceted security approaches to ensure information is kept safe from unauthorized access, use, disclosure, disruption, modification, and destruction. Daily oversight can be supported by software that allows teams to be quickly alerted to potentially dangerous errors and events.

  • Federal Risk and Authorization Management Program (FedRAMP): FedRAMP may be primarily focused on cloud service providers, but agencies have a role to ensure their providers are FedRAMP compliant, and to continually “assess, authorize and continuously monitor security controls that are the responsibility of the agency”. As such, FedRAMP calls for a combination of hands-on processes and technology.

  • Health Insurance Portability and Accountability Act (HIPAA): The response to HIPAA has typically centered on the use of electronic health records, but the Act requires blanket coverage that goes well beyond technology use. As such, healthcare workers need to be conscious of how patient information is shared and displayed.

  • Defense Information Systems Agency Security Technical Implementation Guides (STIGs): The STIGs provide guidelines for locking down potentially vulnerable information systems and software. They are updated as new threats arise. It’s up to federal IT managers to closely follow the STIGs to ensure the software they’re using is not only secure, but working to protect their systems.

Particular types of software can significantly augment the people and processes that support your compliance efforts, so take a closer look at the following tools:

  • Event and Information Management tracks events as they occur on your network and automatically alerts you to suspicious or problematic activity. This type of software uses intelligent analysis to identify events that are inconsistent with predetermined compliant behaviors, and is intelligent enough to issue alerts before violations occur.

  • Configuration Management allows for the configuration and standardization of routers, firewalls, and switches to ensure compliance. This type of software can also be useful in identifying potential issues that might adversely effect compliance before they come to pass.

  • Patch Management is critical for closing known vulnerabilities before they can be exploited. It can be very handy in helping your organization maintain compliance with regards to security and ensuring that all operating systems and applications are updated.

Each of the aforementioned types of software can form a collective safety net for FISMA compliance and serve as a critical component of a security plan, but they can’t be the only component if you’re to achieve your compliance goals. As the old saying goes, the rest is up to you.

Find the full article on our partner DLT’s blog, TechnicallySpeaking.

36 Comments

Compliance is a Culture for Federal IT Professionals.  I know we are trying to do more with less and have the mission be successful, but this does not mean skipping out on doing what is required when we generate a new switch deployment or tech refresh a router.  If the shop was "truly" compliant there would be a baseline configuration for any type of device within their enclave based on DISA STIGs.  Luckily for us Solarwinds NCM users this can be done and managed effectively and efficiently.  For myself, I can take any device and put it on the network, fully STIGed, and operational in 15 minutes.  Then I can add it to my Solarwinds Compliance Dashboard and see where I may fall short on compliance.  But in order for me to get it on the network I use NCM Config Templates to push the required configuration and then add anything I need for the task. 

At the end of the day, if you get in the habit of deploying compliant devices then there is no need to worry when it comes time for an Audit.

Level 14

Compliance starts with people, every time.  However, let's not confuse compliance with security.  One can be compliant without being secure.

Level 10

It should always start with people and it must..all the time. The main reason why we have these regulations are to promote security, we need security to protect people from other people (malicious). So it all boils down to us, and the processes and software we have created are just tools to help us achieve this goal. As mentioned the processes and software won't work on its own, the rest is up to us.

I don't know you'll find any takers for the philosophy of Compliance Starts With Software, unless you dig deep in and talk about writing code that complies with best practices.

I'll take the stand that the software's already out there; it's a tool ready to be used in a safe (a.k.a. "compliant") way, or in a reckless or ignorant way ("non-compliant").

Once you've made the decision to install or use the software, you must use it in a method that complies with some sort of standard, but it doesn't have to be HIPAA or SOX or any other formal method.  Following those guidelines are excellent ways to protect you, your clients, and your company.   Even if you're ignorant of them, you still need to install and use that software via a process that complies with best practices:   safe practices, legal practices, or your own personal code for success.

Level 15

What I can say is that hard to hit it is human material.

MVP
MVP

This reminds me how sad I am when I see how few of the clients I work with are taking advantage of the compliance reports in NCM.  Having a network engineer set up some basic configuration rules really only takes a few hours and being able to document and present up the chain about how your network devices have improved their compliance with the policies of the organization can be an easy win.

I'm a Process Junkie. I believe in that you define the process (aka the "Business Rules"), then you train the people on the process and/or the software.

MVP
MVP

My take on this would be Compliance always starts with INTENT of the organization. If there is Intent only then does the organization invest in People, Process & Technology

MVP
MVP

It starts with people since they are the ones who write and have to adhere to process and decide which software to use.

Level 14

Agreed.  We can have everything configured and secure, and one user clicks on a link in an e-mail.....

Level 14

Whether you work in Federal IT or are bound by Federal Regulators, any effort for Compliance starts with People....

People create,examine,enforce,interperit and implement any regulation.

I agree that people are a key to Compliance (Any Agency or Standard), but it is not only the "people" that are responsible or road block for compliance.  It has to be a culture within the Organization to do business in a compliant manner.  Whether you meet the compliance guideline or not, there still have to be an effort put forth to follow standards prior to a deployment.  We have all been there, we get too busy to do what is required and we end up just getting the circuit/device/network operational then we intend to go back and make it compliant.  Well, more time than not we never get back there for one reason or another. 

I have spoken with many people over the years about being STIG compliant.  Most of the stories go something like this:  Inspection is coming in X# of months.  We need everyone to drop what they are working on and start STIGing the network.  Sometimes it is 4 people and 6 months, 8 people and 7 months, or 1.5 people and 2 months.  The amount of people and time are not important, but the fact they must change their daily business practice to now work compliance.

Since I have been working with NCM and Compliance, I have been able to help these folks in some manner or another.  Showing them a process, templates, hands-on Training, or consultant contract.  Now with the tools (NCM) and the knowledge how to use Compliance feature, they are now able to save man-hours, personnel, and pass with little to no effort.

Level 17

IT always starts with people, but if your Guru's have a lack of understanding for the need and process of creating policy and procedure then you simply lack Intent, as stated by RaviK

Of course you must have a good understanding of users needs and the deliverable items they are counting on. Without the proper understanding and translation of your 'Business Rules', they have a possibility of being over thought and possibly hindering process. I am sure this is not a issue for the ITIL Process Junkie tinmann0715​!

Of course some folks may tell you there's a tool or an app for that - but not for compliance. Even your tools start with a specific agenda to be achieved as they decipher logic and a Hu-Mon begins to code this 'Utility of Compliance'

rschroeder​ knows it's all about the people, and compliance is a state of mind. Because non-compliance is just reckless and ignorant.

All fair points... what we might have here is a Chicken or the Egg scenario when it comes to People/Processes/Software.

Level 17

I am left wondering if  it is the process that created the people, or the people whom created the process......I'll wander for a bit, maybe just a byte.

Level 15

Level 10

I will always say. Technology is never the solution to the process. It only allows the people to accelerate it. You will never fix the compliance problem unless the people are aligned to fix it. The technology will only make their jobs easier in the effort.

Level 13

Too true.  An example I use for some environments I've reviewed in the past is "Yes, critical segment ABC is isolated from the non-trusted segments by a firewall.  Just ignore that 'permit ip any any' line at the top of the ACL."  The existance of a firewall appliance as the only means in/out of the environment allowed for the checking of a box and satisfied somebody's security policy.  However, the configuration reduced the firewall to nothing more than an expensive router and completely violated the intention of the policy.

Level 11

I agree it all goes hand in hand as they compliment each other.

Level 9

I don't necessarily agree with being compliant without being secure (depending on "what" compliance you are striving for).  We have been audited two years now for PCI DSS, FISMA, and SSAE16 Type II.  For the PCI DSS attestation, you must have all of the security controls in place and prove they are there with all of the logs as proof of your controls.  As far as firewall rules, the only access rules permitted should only be those services that are required between segments.  I agree that it starts with the people though, if you do not have the integrity/discipline for establishing and enforcing the rules (no matter if operations says "why are you trying to control everything - it's just making my job harder"), then you have no business being at that company that is required to have compliance in order to grow their business.  As the number of cyber threats is increasing at an alarming rate, I really don't see how compliance can be achieved without the security controls.

Just my $0.02.

Level 9

But you must ensure that those "people" are going to not only follow the rules, but also look for ways to improve the process over time as the business operations evolve.  Policies and processes are only as good as the people that enforce them.

I'd add to shartz​ comment bys saying that you have to have buy-in from key personnel, not just the security team. I've seen people jump through hoops to get through an audit, only for all the good work to be thrown on the "worry about it next year" pile

Level 9

I would not necessarily say intent, but more commitment.  I intend to lose weight this year, but that does not necessarily mean anything unless I have the commitment to perform the necessary actions to do so.  Business all have the same intent which is to make more money this year than last.  But If they can sideline good intentions for compliance to make an extra percentage more this year (whatever theirs may be),   I can pretty much guarantee they will sideline compliance to do so; unless that extra percentage is dependent upon compliance - and then you will see the commitment to the compliance process.

Level 9

IMHO, it's not really the Chicken or Egg scenario here because that is a whole circular thing of evolution.  Compliance is a product of all three, but the driving factor is indeed (1)people, (2)process, (3)software.  It's people (the governing bodies) that determine what compliance is, and the processes to achieve it.  At the business end, tt starts with the people who have to determine what kind of compliance they are looking to achieve - which define the controls they must put into place.  Once the controls are defined, you then have to establish the policies and procedures - which can be achieved without third party compliance software (it may be more time consuming to perform the processes, and the learning curve will be steeper).  All OS's were created by people, and therefore that is where it starts.  Then those people added more security controls (like GPO / ACLs).  Then software was developed upon existing compliance regulations.

Level 9

Too true - the security teams can only recommend what has to be done, they are not the owners of the project, just the project managers.  The decision comes from the top and once that decision has been made, it's up to the security team to put everything into place.  In some cases, the company should have a compliance "team" which involves heads from every department and include the key decision makers.  Case in point, Sarbanes-Oxley - if you are not getting the input regarding department processes from the head of every department, you are not going to get those people to buy-in and remain compliant.

Level 15

good coments.

Level 14

It starts with people to decipher the regulations.  They then have to acquire and configure the software.  And the software always has its limitations.  Some of the regulations REQUIRE that a person look at how the environment is and what policies are in place.  There is not any configuration management software that will do that.  There are also limitations as some configurations will not show is a saved config file, so it cannot be searched for.  You can probably get a 75% software solution, but there will always be a checks that can't be done with software.

Level 11

The deciphering of regulations is key.  You always find different interpretations of the intent of the reg.

Level 14

Those differing interpretations are often based on that person's motivations.  Are they serious about securing the network, or are they just checking the check box?

Level 21

I couldn't agree with you more network defender​!  I personally prefer to focus on security first and then fill in what's left to be compliant.  Our approach to compliance has been to focus on the more strict compliance requirements and if you meet those the less restrictive audits are normally a breeze.

Level 20

You know me Eric... I live in stig hell too!

It is only STIG hell if you do not have Beer and a sense of humor.  

Level 20

Thank goodness I have both of these!  I'm goint to ACAS 5.x training in San Diego next month... the Stone Beer Garden is right down the street from the Marriott where the class is!

MVP
MVP

Don't forget pizza goes well with the beer and sense of humor.

Level 11

A good read to be sure, but I somewhat disagree with the premise. Compliance starts with people, certainly, but from there it balances between software and processes. More to the point, compliance tends to be an area which most closely mirrors leadership aptitude, as those are the people who have to drive and enforce compliance. From there, it's a question of what processes need to be followed in order to be compliant, and what software best enables people to perform those processes. If a process is developed that has no established software capable of supporting it, then the process is just as untenable as if software had been bought and processes awkwardly compelled to use it.

MVP
MVP

Very true, having the software to check compliance and being in compliance are two different things.   For instance, most of the compliance rules in NCM will do things like check to make sure a logging host exists and that its in the right format. 

However, if you only have a single logging host but more are defined on different devices, are they in compliance?  The software will say "yes", but I'm fairly sure for most organizations having logging hosts defined that shouldn't exist is a bad thing.  So having people to not only define the policies, but to check on how they're implemented is crucial!