Securing Medical Devices is a Matter of Life and Death

Read Time:4 Second

The cybersecurity challenges of the Internet of Medical Things (IoMT) are still largely unanswered

Read More

Research on AI in Adversarial Settings

Read Time:51 Second

New research: “Achilles Heels for AGI/ASI via Decision Theoretic Adversaries“:

As progress in AI continues to advance, it is important to know how advanced systems will make choices and in what ways they may fail. Machines can already outsmart humans in some domains, and understanding how to safely build ones which may have capabilities at or above the human level is of particular concern. One might suspect that artificially generally intelligent (AGI) and artificially superintelligent (ASI) will be systems that humans cannot reliably outsmart. As a challenge to this assumption, this paper presents the Achilles Heel hypothesis which states that even a potentially superintelligent system may nonetheless have stable decision-theoretic delusions which cause them to make irrational decisions in adversarial settings. In a survey of key dilemmas and paradoxes from the decision theory literature, a number of these potential Achilles Heels are discussed in context of this hypothesis. Several novel contributions are made toward understanding the ways in which these weaknesses might be implanted into a system.

Read More

CREST publishes guide for enhancing cyber resilience in developing countries

Read Time:32 Second

International information security accreditation and certification body CREST has published a new guide to fostering financial sector cyber resilience in developing countries. The nonprofit’s Resilience in Developing Countries paper forms part of its work in encouraging greater cyber readiness and resilience in emerging nations to help protect key industries from cyberattacks.

The guide outlines that, while increased financial inclusion is a global goal, the less privileged remain highly susceptible to cyberthreats. It also describes the need for appropriate, multi-party cyber resilience testing to ensure better cyber safety in developing nations, along with advice for governing authorities.

To read this article in full, please click here

Read More

Identity and Access Management (IAM) in Payment Card Industry (PCI) Data Security Standard (DSS) environments.

Read Time:5 Minute, 9 Second

This is the first of a series of consultant-written blogs around PCI DSS.

Many organizations have multiple IAM schemes that they forget about when it comes to a robust compliance framework such as PCI DSS.

There are, at minimum, two schemes that need to be reviewed, but consider if you have more from this potential, and probably incomplete, list:

Cloud service master account management AWS (Amazon Web Services), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Architecture (OCA),
Name Service Registrars (E.g., GoDaddy, Network Solutions)
DNS service (E.g., Akamai, CloudFront)
Certificate providers (E.g., Entrust, DigiCert)
IaaS (Infrastructure as a Service) and SaaS (Software as a Service)) accounts (E.g.: Digital Realty, Equinix, Splunk, USM Anywhere (USMA), Rapid7)
Servers and networking gear administrative account management (Firewalls, routers, VPN, WAF, load balancer, DDoS prevention, SIEM, database, Wi-Fi)
Internal user account management, (Active Directory, LDAP or equivalent, and third parties who may act as staff augmentation or maintenance and repair services, API accesses)
Consumer account management (often self-managed in a separate database using a different set of encryption, tools and privileges or capabilities, from staff logins).
PCI DSS v4.0 expands the requirement to all system, automated access, credentialed testing, and API interfaces, so those need to be considered too.

Bottom line, in whatever fashion someone or something validates their authorization to use the device, service, or application, that authorization must be mapped to the role and privileges afforded to that actor. The goal being to ensure that each is provisioned with the least-privilege needed to be able to complete its or their intended function(s) and can be held accountable for their actions.

As many of the devices as possible should be integrated into a common schema, since having multiple devices with local only admin accounts is a recipe for disaster.

If privilege escalation is possible from within an already-authenticated account, the mechanism by which that occurs must be thoroughly documented and monitored (logged) too.

PCI DSS Requirement 7 asks the assessor to review the roles and access privileges and groupings that individuals could be assigned to, and that those individuals are specifically authorized to have those access rights and roles. This covers both physical and logical access.

Requirement 9 asks specifically about business-based need and authorization for visitors gaining physical access to any sensitive areas. Frequent visitors such as janitors and HVAC maintenance must be remembered when writing policy and procedures and when conferring access rights for physical access.

Requirement 8 then asks the assessor to put together the roles, privileges, and assignments with actual current staff members, and to validate that the privileges those staff currently have, were authorized, and match the authorized privileges. This is one of the few for-ever requirements of PCI DSS, so if paperwork conferring and authorizing access for any individuals or automation has been lost, it must be re-created to show authorization of the current access rights and privileges.

PCI DSS v4.0 requires much more scrutiny of APIs – which are a growing aspect of application programming. The design engineers need to ensure that APIs and automated processes are given, or acquire, their own specific, unique, authorization credentials, and the interface has session control characteristics that are well-planned, documented, and managed using the same schema created for Requirement 7. Cross-session data pollution and/or capture must be prevented. If the API is distributed as a commercial off-the-shelf (COTS) product, it cannot have default credentials programmed in, but the installation process must ask for, or create and store appropriately, strong credentials for management and use.

Requirements 1 and 6 both impact role and privilege assignments also, where separation of duties between development and production in both networking and code deployment is becoming blurred in today’s DevSecOps and agile world. However, PCI’s standard remains strict and requires such separations, challenging very small operations. The intent is that no one person (or login ID) should have end-to-end control of anything, and no-one should be reviewing or QA’ing and authorizing their own work. This might mean a small organization needs to contract one or more reviewers1 if there’s one person doing development, and the other doing deployment.

Even in larger organizations where developers sometimes need access to live production environments to diagnose specific failures, they must not be using the same login ID as they use for development. Organizations could choose asmith as the developer role and andys as the administrative login ID for the same person, to ensure privilege escalations are deliberately bounded and easily trackable (per requirement 10). Also, no-one should ever be using elevated privileges to perform their day-to-day job; elevations should always be used for point tasks and dropped as soon as they are no longer needed.

Next, third parties allowed into your cardholder data environment (CDE) – for maintenance purposes for instance – must always be specifically authorized to be there (physically or logically) and monitored while they are there. Most SIEM tools these days monitor everything indiscriminately, but PCI also says their access must be cut off as soon as it is no longer needed.

That might mean time-bounding their logical access, and it does mean escorting them while they are present. Staff must also be empowered and encouraged to challenge people with no badge, or no escort, and to escort them out of any sensitive area until their escort can be reunited with them. If your staff has access to customer premises where PCI-sensitive data is present, (either physically or logically) they must conduct themselves in like manner.

PCI DSS v4.0 also adds a requirement that any normally automated process that can be used interactively (e.g. for debugging) must log any of the interactive usage that occurs, with the appropriate individual’s attribution.

Lastly, PCI DSS 4.0 adds credentialed testing using high access privileges for requirement 11 (although not necessarily administrative privilege), which requires those credentials to be designed into the overall requirement 7 schema and subjected to the requirement 8 restrictions and constraints.

1Reviewers are secure-code reviewers and security-trained functional QA staff.

Read More

Cyber threat intelligence programs: Still crazy after all these years

Read Time:30 Second

When I asked CISOs about their cyber threat intelligence (CTI) programs about five years ago, I got two distinct responses. Large, well-resourced enterprises were investing their threat intelligence programs with the goal of better operationalizing it for tactical, operational, and strategic purposes. Smaller, resource-constrained and SMB organizations often recognized the value of threat intelligence, but didn’t have the staff, skills, or budgets for investment. For these organizations, threat intelligence programs were nothing more than blocking indicators of compromise (IoCs) with firewalls, endpoint security software, email gateways, or web proxies.

To read this article in full, please click here

Read More