Healthcare and Technology news
48.6K views | +0 today
Follow
Healthcare and Technology news
Your new post is loading...
Your new post is loading...
Scoop.it!

Top 3 Third Party Risk Management Challenges

Top 3 Third Party Risk Management Challenges | Healthcare and Technology news | Scoop.it

Since the massive Target data security breach in December 2013, third party cyber security stopped being an afterthought and started becoming one of the top security priorities for CISOs and Risk Departments. As a response, Third Party Risk Management (TPRM) underwent a transformation in early 2014, and continues to reverberate today.

 

With attackers finding new ways to break into third parties in hopes of infecting a larger organization, the third party ecosystem is more susceptible than ever before. Meanwhile third party usage is growing fast in large organizations and enterprises. Many critical business services such as HR functions, data storage, and modes of communication are the responsibility of cloud-based third parties.

 

Without a modern TPRM program, many of these third parties are left behind in security risk management, putting organizations in a vulnerable position.

 

Over 60% of data breaches can be linked either directly or indirectly to a third party (per Soha Systems, 2016) but TPRM programs don’t often take a risk-first perspective when it comes to risk management. Security and Vendor Risk departments are often solely focused on compliance. That’s important, but doesn’t get at the heart of the risk posed by your third parties. To shift the approach of your TPRM program to measure true risk, you’ll need to make some adjustments in how you manage third parties.

 

Here are the three top TPRM challenges and the actions you and your organization can take in order to bolster your TPRM program.

 

1. Automate Your TPRM Process to Reduce Unmanaged Risk
With the rise in SaaS, businesses are now using cloud-based third parties more than ever. Gartner predicted that SaaS sales will nearly double by 2019, and that SaaS applications will make up 20% of the growth rate in all public cloud services, a $204B market. Last year, Forrester had already predicted that enterprise spend on software would reach $620B by the end of 2015.

 

As businesses engage in IT and infrastructure digital transformation, the need to manage vendors is more pronounced. Over 60% of respondents from a Ponemon Institute’s survey on Third Party Risk Management believe that the Internet of Things increases third party risk significantly. 68% believe the same is true for cloud migration.

 

However, as more third parties are brought in, they’re often not managed to match the level of cyber security risk they carry. Worse, they may not be managed at all due to a lack of resources. This creates unmanaged security risk. If these third parties have access to your network, your employees’ PII, or your customers’ sensitive data, shouldn’t they be subject to rigorous risk management assessments?

 

Unfortunately, as the number of third parties swell to the hundreds, it’s often not feasible for every vendor to be assessed in the same critical fashion. That’s why having an automated risk assessment tool for assessing vendors is a way to ensure you’re minimizing unmanaged risk from both new and existing vendors.

 

Automating your TPRM process is one of the major steps towards having a mature TPRM department capable. Its benefits include:

 

  • Improved third party management flexibility
  • Standardized processes and thirdparty management
  • Metrics and reporting consistency
  • Improved data-driven decision making
  • Further structuring the TPRM organization
  • Increased third party responsibility
  • Increased overall risk assessment and mitigation

 

By automating the TPRM process, you’re creating a standardized structure that can be applied to all third parties, whether existing or onboarded.

 

You can automate your TPRM process by finding new technologies or tools that will automate the assessment and information gathering process for your third party vendors. This helps to ensure that you’re optimizing your resources and spending company time on what is most impactful.

 

2. Augment and Validate Self-Reported Questionnaires Through Independent Risk-Based Assessments
Third parties are often assessed through questionnaires, onsite assessments, or via penetration tests. Each has its own advantages and disadvantages. Onsite risk assessments and penetration tests are resource-intensive, requiring time, money, and staff in order to carry out the assessments. Because of the costs, these kinds of assessments cannot be used for all third parties, and should be reserved for the most risk-critical third parties.

 

That leaves questionnaires to fill the void for most of the other third parties. However, questionnaires are self-reported, which makes using a ‘trust, but verify’ approach to risk management difficult to accomplish.

 

In a 2016 Deloitte Study on Third Party Risk Management, 93.5% of respondents expressed moderate to low levels of confidence in their risk management and monitoring mechanisms. With numbers like that, it’s easy to see why TPRM programs need increased attention. Without a way to independently verify the security posture of your third parties, you can only rely on the word of your third parties who are, for obvious reasons, incentivized to report positively.

 

Organizations should find independent third parties that can provide risk-based assessments of their third parties to validate that the findings from questionnaires are a realistic portrait of the state of third party security.

 

There are a number of cyber security solutions that provide risk-first third party assessments. To find the right solution, you should research whether or not those solutions:

 

  • are accurately assessing third parties
  • can facilitate communication between you and third parties
  • are focusing on key cyber security areas that are indicative of a potential breach


3. Utilize Continuous Monitoring to Assess Third Parties Beyond Point-In-Time Assessments
The assessment methods mentioned in the previous section all have one glaring flaw in common – they assess third parties at a single point in time. Many times, the information gathered by security risk assessments is outdated by the time it falls into your hands. The speed at which hackers are developing new attacks and exploiting vulnerabilities is too fast for point-in-time assessments or annual reviews to provide any insight into the real security posture of a vendor.

 

A PWC Third Party Risk Management report on the finance industry noted that 58% of companies using ad hoc monitoring experienced a third party service disruption or data breach, compared to only 37% of those that regularly monitor their providers and partners. Without having a way to know the security posture of your third parties on-demand, you’re managing risk with a blindfold on for most of the year. By only having point-in-time information that is quickly outdated, your ability to react to new vulnerabilities, or worse, a potential third party cyber security incident, is negligible.

 

Through continuous monitoring, you’re bolstering the security of your third party by keeping them consistently accountable, which in turn, minimizes your overall risk to a potential security incident.

 

How to Get Started Revamping Your VRM
We covered how to implement continuous monitoring in your TPRM program in part 2 of our How to Revamp Your VRM Program article series. Start by establishing a central TPRM office if you don’t already have one, prioritize and identify your most risk-critical and business-critical vendors, and then define your third parties’ security controls and processes that you’ll monitor on an ongoing basis. If you have the resources, look for automated risk healthassessment tools and solutions that offer continuous monitoring for your third parties.

 

Conclusion
Updating your TPRM program doesn’t have to be a complete overhaul of your department. Instead, you should use a risk-first perspective to define the aspects that are the most criticalto update. The three we highlighted here will yield the most dramatic changes in a TPRM program, reducing your unmanaged risk, and reducing your reaction time should a security incident occur.

 

By automating aspects of your TPRM program, using independent third party assessments, and adopting continuous monitoring, you’re not far from having a mature TPRM program that can easily assess any new third party as it comes, keeping your organization safe.

Technical Dr. Inc.'s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

more...
No comment yet.
Scoop.it!

Compromised logs can hamper IT security investigations 

Compromised logs can hamper IT security investigations  | Healthcare and Technology news | Scoop.it

At the heart of most devices that provide protection for IT networks is an ability to log events and take actions based on those events. This application and system monitoring provides details both on what has happened to the device and what is happening. It provides security against lapses in perimeter and application defences by alerting you to problems so defensive measures can be taken before any real damage is done. Without monitoring, you have little chance of discovering whether a live application is being attacked or has been compromised.

 

Critical applications, processes handling valuable or sensitive information, previously compromised or abused systems, and systems connected to third parties or the Internet all require active monitoring. Any seriously suspicious behaviour or critical events must generate an alert that is assessed and acted on. Although you will need to carry out a risk assessment for each application or system to determine what level of audit, log review and monitoring is necessary, you will need to log at least the following:

  • User IDs
  • Date and time of log on and log off, and other key events
  • Terminal identity
  • Successful and failed attempts to access systems, data or applications
  • Files and networks accessed
  • Changes to system configurations
  • Use of system utilities
  • Exceptions and other security-related events, such as alarms triggered
  • Activation of protection systems, such as intrusion detection systems and antimalware

Collecting this data will assist in access control monitoring and can provide audit trails when investigating an incident. While most logs are covered by some form of regulation these days and should be kept as long as the requirements call for, any that are not should be kept for a minimum period of one year, in case they are needed for an investigation.  However, monitoring must be carried out in line with relevant legislation, which in the UK is the Regulation of Investigatory Powers and Human Rights Acts. Employees should be made aware of your monitoring activities in the network acceptable use policy.

 

 

Log files are a great source of information only if you review them. Simply purchasing and deploying a log management product won’t provide any additional security. You have to use the information collected and analyse it on a regular basis; for a high-risk application, this could mean automated reviews on an hourly basis. ISO/IEC 27001 control A.10.10.2 not only requires procedures for monitoring the use of information processing facilities, but demands the results are reviewed regularly to identify possible security threats and incidents.

 

However, even small networks can generate too much information to be analysed manually. This is where log analysers come in, as they automate the auditing and analysis of logs, telling you what has happened or is happening, and revealing unauthorised activity or abnormal behaviour. This feedback can be used to improve IDS signatures or firewall rule sets. Such improvements are an iterative process, as regularly tuning your devices to maximise their accuracy in recognising true threats will help reduce the number of false positives. Completely eliminating false positives, while still maintaining strict controls, is next to impossible, particularly as new threats and changes in the network structure will affect the effectiveness of existing rule sets. Log analysis can also provide a basis for focused security awareness training, reduced network misuse and stronger policy enforcement.

 

ISO/IEC 27001 controls A.10.10.4 and A.10.10.5 cover two specific areas of logging whose importance is often not fully appreciated: administrator activity and fault logging. Administrators have powerful rights, and their actions need to be carefully recorded and checked. As events, such as system restarts to correct serious errors, may not get recorded electronically, administrators should maintain a written log of their activities, recording event start and finish times, who was involved and what actions were taken. The name of the person making the log entry should also be recorded, along with the date and time. The internal audit team should keep these logs.

 

There are two types of faults to be logged: faults generated by the system and the applications running on it, and faults or errors reported by the system's users. Fault logging and analysis is often the only way of finding out what is wrong with a system or application. The analysis of fault logs can be used to identify trends that may indicate more deep-rooted problems, such as faulty equipment or a lack of competence or training in either users or system administrators.

 

All operating systems and many applications, such as database server software, provide basic logging and alerting faculties. This logging functionality should be configured to log all faults and send an alert if the error is above an acceptable threshold, such as a write failure or connection time-out. The logs should be reviewed on a regular basis, and any error-related entries should be investigated and resolved. While analysing all logs daily is likely an unrealistic goal, high-volume and high-risk applications, such as an e-commerce Web server, will need almost daily checking to prevent high-profile break-ins, while for most others a weekly check will suffice.

 

There should be a documented work instruction covering how faults are recorded or reported, who can investigate them, and an expected resolution time, similar to a service contract if you use an outside contractor to support your systems. Help desk software can log details of all user reports, and track actions taken to deal with them and close them out.

 

No matter how extensive your logging, log files are worthless if you cannot trust their integrity. The first thing most hackers will do is try to alter log files to hide their presence. To protect against this, you should record logs both locally and to a remote log server. This provides redundancy and an extra layer of security as you can compare the two sets of logs against one another -- any differences will indicate suspicious activity.

 

If you can’t stretch to a dedicated log server, logs should be written to a write-once medium, such as a CD-R or DVD-R, or to rewritable media such as magnetic tape data storage or hard disk drives that automatically make the newly written portion read-only to prevent an attacker from overwriting them. It's important also to prevent administrators from having physical and network access to logs of their own activities. Those tasked with reviewing logs should obviously be independent of the people, activities and logs being reviewed.

 

The protection of log information is critical. Compromised logs can hamper IT security investigations into suspicious events, invalidate disciplinary action and undermine court actions.

 

Another point to bear in mind is system clocks need to be synchronised so log entries have accurate timestamps. Check computer clocks and correct any significant time variations on a weekly basis, or more often, depending on the error margin for time accuracy.

 

Clocks can drift on mobile devices and should be updated whenever they attach to the network or desktop. Always record the time of an event in a consistent format, such as Universal Coordinated Time (UTC) across all files. For additional security, add a checksum to each log entry so you can detect if any entries have been tampered with. Controls also need to be in place to ensure there is ample log storage. If your logs can be trusted, they can help you reconstruct the events of security incidents and provide legally admissible evidence.

 

Logging and auditing work together to ensure users are only performing the activities they are authorised to perform, and they play a key role in preventing, as well as in spotting, tracking and stopping unwanted or inappropriate activities.

Technical Dr. Inc.'s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

 
more...
No comment yet.