Home Tags Risk Assessment

Tag: Risk Assessment

Balbix Launches Predictive Security Breach Risk Assessment Platform

Former CEO of virtualization security vendor Bromium launches new startup that makes use of machine learning techniques to help detect and predict risk.

MyLife Digital celebrates ISO 27001 certification

MyLife Digital is delighted to announce its successful certification for the ISO 27001 information security standard.Audited by LRQA, MyLife Digital ran various early initiatives as part of the robust requirements for certification.
It also implemented a rigorous staff training and awareness programme for information security, as well as running effective risk assessment and risk treatment activities.John Hall, CEO of MyLife Digital, commenting on the achievement, says, “As an organisation handling the personal data of millions... Source: RealWire

Mimecast Tackles Email-Bound Risks

At RSA, Mimecast cyber security strategy Bob Adams discusses graduating from basic filtering to true email security risk assessment.

IBM Security Acquires Risk Management Vendor Agile 3 Solutions

IBM adds new risk management capabilities to its security portfolio in a bid to further strengthen the security immune system. IBM announced on Jan. 23 its intent to acquire privately-held Agile 3 Solutions, in an effort to further improve IBM Security's risk management capabilities.

Financial terms of the deal are not being publicly disclosed.Agile 3 Solutions is an IT risk management vendor with several different products and services.

Among Agile 3's products is a service called Business Exposure and Risk Management (BERM), which aims to help provide visibility into potential security risks that could impact a business.

The Business Program Management and Compliance (BPMC) service from Agile 3, provides a management dashboard for organization to track metrics that are aligned with compliance efforts.

The Agile 3 Business GRC: iDNA is a platform that helps organizations to map potential threats against business assets.Gregg Barrow, Partner, Global Competency Leader, Data and Application Security Services at IBM Security explained that Agile 3 Solutions provides specific technology that is able to harvest information about risks and exposures to sensitive data across an organization. He noted that in addition to collecting and analyzing business risk information, the Agile 3 technology provides an intuitive, graphical user dashboard that is designed specifically for executive-level use."The Agile 3 dashboard provides Line of Business-level detail that helps executives understand what pieces of data are at risk, how significant the risk is, which Line of Business is responsible for the data, and more items," Barrow told eWEEK. "Agile 3's technology is able to collect its own business-level risk data and can also be fed data from data security and other products to collect, analyze and present a single business-level view of business risk to data." While Agile 3 does provides capabilities that can fit into the Governance, Risk and Compliance (GRC) market, Barrow commented that Agile 3 does not directly compete with GRC tools. Rather he noted that Agile 3 is focused on providing a data security risk assessment of the enterprise data, how to remediate risk and communicate the risk posture to the business. "Agile 3 Solutions integrates with IBM Security Guardium capabilities to remediate data security concerns," Barrow said.In terms of where the Agile 3 technology will fit into the IBM Security product portfolio, Barrow said that it will augment the existing data security capabilities from IBM Security Guardium and IBM Data and Application Security Services. He noted that Agile 3 recently partnered with the Guardium team to engage with clients, and jointly perform proof of concepts."Agile 3 has the ability to apply its technology broadly across the IBM Security portfolio," Barrow said. "In the coming months, IBM Security will be exploring ways to further integrate Agile 3 technology and leverage it across areas of the portfolio."IBM calls its approach to layering and embedding security across an organization, the 'security immune system.' The basic idea is that by layering security across the entire 'body' of an organization, technology can fight threats in a way similar to how antibodies fight disease.

The Agile 3 technology is set to become another element in the growing IBM security immune system."By having a broad set of tightly integrated security capabilities woven throughout a company’s infrastructure, these systems can work together to proactive detect and combat various threats throughout the multiple stages of an attack's lifecycle," Barrow said.Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com.

Follow him on Twitter @TechJournalist.

JSA10771 – 2017-01 Security Bulletin: Junos: Denial of Service vulnerability in...

2017-01 Security Bulletin: Junos: Denial of Service vulnerability in RPD (CVE-2017-2302)Product Affected:This issue can affect any product or platform running Junos OS. Problem: On Junos OS devices where the BGP add-path feature is enabled with 'send' ...

JSA10774 – 2017-01 Security Bulletin: Network and Security Manager (NSM): Multiple...

2017-01 Security Bulletin: Network and Security Manager (NSM): Multiple OpenSSH vulnerabilities affect NSM Appliance OS.Product Affected:NSM Appliances (NSM3000, NSM4000 and NSMExpress). Problem: Multiple OpenSSH software vulnerabilities affect NSM App...

JSA10772 – 2017-01 Security Bulletin: Junos: RPD crash while processing RIP...

2017-01 Security Bulletin: Junos: RPD crash while processing RIP advertisements (CVE-2017-2303)Product Affected:This issue can affect any product or platform running Junos OS where RIP is enabled. Problem: Certain RIP advertisements received by the rou...

JSA10773 – 2017-01 Security Bulletin: QFX3500, QFX3600, QFX5100, QFX5200, EX4300 and...

2017-01 Security Bulletin: QFX3500, QFX3600, QFX5100, QFX5200, EX4300 and EX4600: 'Etherleak' memory disclosure in Ethernet padding data (CVE-2017-2304)Product Affected:This issue affects QFX3500, QFX3600, QFX5100, QFX5200, EX4300 and EX4600 devices. Problem: QFX3500, QFX3600, QFX5100, QFX5200, EX4300 and EX4600 devices do not pad Ethernet packets with zeros, and thus some packets can contain fragments of system memory or data from previous packets.

This issue is also known as 'Etherleak' and often detected as CVE-2003-0001. Juniper SIRT is not aware of any malicious exploitation of this vulnerability. This issue has been assigned CVE-2017-2304. Solution: The following software releases have been updated to resolve this specific issue: Junos OS 14.1X53-D40, 15.1X53-D40, 15.1R2  and all subsequent releases. This issue is being tracked as PR 1063645 and is visible on the Customer Support website. KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. Workaround: There are no known workarounds to prevent the information leak in Ethernet packets. It is a good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the QFX device only from trusted, administrative networks or hosts. Implementation: Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version.
In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame.

For these cases, Service Releases are made available in order to be more timely.
Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release.

Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Modification History: 2017-01-11: Initial release. Related Links:CVSS Score:4.3 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) Risk Level:Low Risk Assessment:Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

JSA10768 – 2017-01 Security Bulletin: Junos: SRX Series denial of service...

2017-01 Security Bulletin: Junos: SRX Series denial of service vulnerability in flowd due to crafted multicast packets (CVE-2017-2300)Product Affected:This issue affects any SRX Series Services Gateway chassis cluster Problem:The flowd daemon on the primary node of an SRX Series chassis cluster may crash and restart when attempting to synchronize a multicast session created via crafted multicast packets.  Upon the flowd crash, data plane redundancy groups will fail over to the secondary node in the chassis cluster while flowd on the primary node restarts.This issue only occurs in chassis cluster configurations that process transit multicast traffic.  Transit multicast traffic is processed on an SRX services gateway by enabling PIM in normal Flow Mode, or via security policies permitting transit multicast traffic in L2/Transparent Mode.Juniper SIRT is not aware of any malicious exploitation of this vulnerability.No other Juniper Networks products or platforms are affected by this issue.This issue has been assigned CVE-2017-2300. Solution:The following software releases have been updated to resolve this specific issue: Junos OS 12.1X46-D65, 12.3X48-D40, 15.1X49-D60, and all subsequent releases.This issue is being tracked as PR 1188853 and is visible on the Customer Support website.KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. Workaround:Disallow transit multicast traffic, or isolate/disable the secondary node of the chassis cluster until an upgrade can be performed. For SRXs running in Transparent Mode, any security policies permitting transit multicast traffic should be disabled (default policy is deny-all). For SRXs running in normal Flow Mode, transit multicast traffic can also be stopped by disabling PIM protocol. Implementation:How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version.
In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame.

For these cases, Service Releases are made available in order to be more timely.
Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release.

Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.Modification History: 2017-01-11: Initial publication2017-01-18: Devices with security policies permitting transit multicast traffic in Transparent Mode are also vulnerable Related Links:CVSS Score:6.5 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Risk Level:Medium Risk Assessment:Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

MongoDB Ransomware Impacts Over 10,000 Databases

Open, unauthenticated MongoDB database instances are being attacked by multiple groups of attackers, that are encrypting data and demanding a ransom from victims. Attackers are exploiting misconfigured open-source MongoDB databases and holding them for ransom.

The ransomware attacks against MongoDB were first publicly reported by GDI Foundation security researcher Victor Gevers on Dec. 27, 2016, and have been steadily growing ever since, with at least five different groups of hackers taking control of over 10,000 database instances.Among the most recent groups to join the MongoDB ransomware attack was one reported on Jan. 6, by security researcher Nial Merrigan.

The MongoDB attackers are only identified by the email address that is used to demand payment.

The new group identified as 3lix1r@mail2tor.com, has already compromised at least 17 MongoDB instances, and is demanding 0.25 Bitcoin from victims to get the data back.An active list of the growing number of attacker groups participating in the attack is now being maintained on Google Docs.

The amounts being demanded by attackers vary from a low of 0.15 Bitcoin up to a full Bitcoin.

Bitcoin has fluctuated in value so far in 2017, and as of Jan 6, is worth approximately $892 USD.The attack against MongoDB is a fairly simple one and is taking advantage of databases that have been misconfigured and left open, without the need for a user to first have proper administrative credentials. Once the attackers log into the open database, the next step is to fully take control and then steal or encrypt the database, offering it back to the victims only on receipt of the Bitcoin ransom payment. The fact that many MongoDB database instances have been left open, is not a new phenomena.

Back in December 2015, security researcher Chris Vickery used the Shodan search tool to find MongoDB servers with open ports.

At the time, Vickery was able to find a misconfigured MongoDB databases used by Kromtech, developer of the MacKeeper Mac OS X utility program. Shodan founder John Matherly followed up on Vickery's research and also reported in December 2015 that at the time, there were at least 35,000 publicly available, unauthenticated instances of MongoDB on the internet. Just over a year later, now in January 2017, the number of open MongoDB databases hasn't declined, it's actually likely larger, with some estimates suggesting that there could up to 99,000 databases at risk.The solution to the MongoDB security risk involves database administrators following the security checklist that MongoDB outlines on its website.

The very first item on the checklist is 'enable access control and enforce authentication.'Security researchers contacted by eWEEK were not surprised that MongoDB is being targeted by ransomware attackers."Given MongoDB's popularity and usage in production environments, it is not surprising that the open-source DB was targeted," Zohar Alon, Co-Founder and CEO for Dome9, told eWEEK. "Very often, misconfigurations and oversights in the way the database is deployed create vulnerabilities that attackers can exploit."Alon added that user errors coupled with weak security practices continue to jeopardize workloads running in cloud environments. He suggests that before using third-party software such as an open-source database, users should educate themselves about best practices and known vulnerabilities."It's interesting that most people think databases are secure because they are blocked behind firewalls and data centers," RiskVision CTO Jean-François Dubé told eWEEK. "The problem is that attackers can still get into the servers that house the information through consumer endpoints and third party connections."Dubé recommends that databases in general, should be constantly assessed for risk."Enterprises that monitor their databases in near real-time with risk assessment tools are better able to see what is happening when unencrypted data moves out of the database," he said.Matthew Gardiner, Cybersecurity Strategist at Mimecast commented that he wasn't surprised at all by the MongoDB attack."When one places open, unauthenticated, and vulnerable data stores – or any systems for that matter - on the Internet by the thousands, the bigger question is what took the attackers so long to blow them up?" Gardiner said.Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com.

Follow him on Twitter @TechJournalist.

A Vendor's Security Reality: Comply Or Good-Bye

Privacy compliance is now mission critical.

Third-party suppliers that fail to meet data protection mandates will be excluded from doing business in lucrative vertical markets. The Health Insurance Portability and Accountably Act (HIPAA) Omnibus Rule and the Federal Information Security Management Act (FISMA) have introduced an unprecedented emphasis on third-party compliance.

For those providing services within the healthcare sector or to the federal government, privacy compliance is now mission critical.

Although vendor compliance has long been clouded in ambiguity, these directives provide much needed and long-overdue clarity to the vast vendor community. Unfortunately, many vendors have yet to address their compliance obligations and are now scrambling to salvage customer relationships.

Federal regulators, awakened by the expansion of outsourcing and the unending drumbeat of vendor breaches, have turned their focus directly toward service providers and the risks they pose.

The result is that vendors face a new and stark reality: comply or good-bye.

Those that fail to meet specific data protection mandates ultimately will be excluded from doing business in these lucrative vertical markets. HIPAA Omnibus RuleThe HIPAA Omnibus Rule represents a dramatic change to healthcare regulation and jolted the vendor community.

Although enacted in 2009 as part of the Health Information Technology for Economic and Clinical Health (HITECH) Act, the effective date was postponed until September 2013.

The Omnibus Rule addresses important issues such as disclosure and patient rights, but the most significant change, from a data protection perspective, relates to the responsibilities of "business associates" — any entity that "creates, receives, maintains or transmits protected health information on behalf of a health care provider or insurer." Before September 2013, healthcare vendors were required to meet minimal data protection standards, while hospitals, health clinics, and insurance plans were subject to the full scope of HIPAA's Privacy and Security Rules.

The Omnibus Rule, however, subjects vendors to requirements that had previously applied only to covered entities.

Therefore, vendors must implement a combination of administrative, technical, and physical safeguards to ensure the security of protected health information or be exposed to the consequences of a regulatory violation. Specifically, vendors are required to: Conduct a formal risk assessment Implement measures to mitigate internal and external risk Implement written policies governing the security of protected health information Conduct data security training for all employees Restrict physical access to storage of protected health information Protect workstations and electronic media Implement technologies to prohibit unauthorized access Log all electronic access of protected health information Secure electronically transmitted protected health information In addition to experiencing disruption of customer relationships, healthcare vendors are now exposed to significant financial penalties from the Department of Health and Human Services for failure to comply with HIPAA.
Should you doubt the government's resolve in enforcing the rigorous business associate requirements, several vendors have been fined in excess of $500,000 since the implementation of the Omnibus Rule. FISMAFISMA was enacted in 2002 as a framework for ensuring the security of systems that support government operations.
It requires all federal agencies, entities administering federally funded programs, federal grant recipients, and government contractors to develop, document, and implement a program to secure federal information and corresponding systems.

FISMA mandates that those subject to the law implement "baseline security controls" through a combination of managerial, operational, and technical measures and is aligned with NIST 800-53, the National Institute of Standards and Technology's outline of security controls for federal information systems. Although third-party service providers have been subject to FISMA since its enactment, vendor compliance has been prioritized over the past few years.

This development has prompted government contractors to pursue FISMA compliance or risk exclusion from the federal vendor community.

Enforcement of FISMA's third-party standard is being performed primarily through the procurement process, with all prospective vendors required to attest to adherence with rigorous data security controls when responding to a solicitation.

The specific language within contract awards mandates that vendors submit evidence of FISMA compliance in the form of monthly, quarterly, and annual deliverables. Accordingly, if your company is doing business with a government agency, you will be required to provide detailed and ongoing evidence of compliance.

Additionally, agencies are increasingly deploying audit teams to perform on-site verification of a vendor's control environment. The following list, taken directly from a Federal Highway Administration RFP, details the specific documents that vendors must provide as evidence of FISMA compliance: Security assessment: formal evaluation of control environment (annual) Plan of action: plan to mitigate assessment findings (quarterly) System security plan: documentation of all controls (annual) Security categorization: impact level of each system (annual) System contingency plan: documentation of redundancy (annual) Security policy and workforce training records (annual) Interconnection agreements from sub-contractors (annual) The New RealityAlthough meeting the enhanced requirements of HIPAA or FISMA will entail additional resources, third-party service providers should view this as a critical, long-term investment.

The reality is that vendors operating within highly regulated industries must be capable of demonstrating compliance to each customer.

Therefore, those who are unable to meet the new regulatory mandates will find themselves on the outside, looking in. Related Content: John Moynihan, CGEIT, CRISC, is President of Minuteman Governance, a Massachusetts cybersecurity consultancy that provides services to public and private sector clients throughout the United States. Prior to founding this firm, he was CISO at the Massachusetts Department of ...
View Full Bio More Insights

IT Professionals Cyber-Security Confidence Falls From a Year Ago

As 2016 races to its conclusion, IT professionals around the world don't have a tremendous amount of confidence for improved cyber-security in 2017.

Tenable Network Security released its 2017 Global Cybersecurity Assurance Report Card Dec. 5, providing insight into cyber-security confidence perspectives based on a survey of 700 security professionals across nine countries and seven different industry verticals. On a global basis, the global cyber-security confidence score came in at 70 percent, or a C- grade, down six points from 2016. Looking at specific geographies, India ranked first overall at 84 percent, while the United States came in second at 78 percent.

At the bottom of the list, Japan—the only country to get a failing grade—came in at 48 percent.
In terms of industry verticals, Retail ranked the highest, at 76 percent, while Government ranked the lowest, at 63 percent.

The report card is comprised of a Security Assurance Index score as well as a Risk Assessment Index score.

Among the key trends on the Risk Assessment side is a sharp decline in security professionals' ability to assess mobile security properly.

For the 2017 report, the risk assessment score for mobile devices came in at 57 percent, down from 65 percent in 2016.
In this slide show, eWEEK takes a look at some of the key highlights from the Tenable Network Security 2017 Global Cybersecurity Assurance Report Card.