Great read! I’ve saved your site and I’m including your RSS feeds to my Google
account.

The U.S. Food and Drug Administration (FDA) has released guidance on the postmarket management of cybersecurity for medical devices, encouraging manufacturers to implement security controls that cover products throughout their entire life cycle.

In 2014, the FDA released guidance for the premarket management of cybersecurity. The recommendations include limiting access to trusted users via various authentication methods, ensuring that only authorized firmware and software can be installed, and implementing features for cyber incident detection, response and recovery.

The new guidance issued by the FDA focuses on managing cybersecurity risks after the devices have been deployed on a hospital’s network, a patient’s home network, or in a patient’s body.

http://www.securityweek.com/fda-publishes-cybersecurity-guidance-medical-device-manufacturers

Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf

Postmarket Management of Cybersecurity in Medical Devices
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM482022.pdf

The best quote from the talk? “Cryptography is rarely, if ever, the solution to a security problem. Cryptography is a translation mechanism, usually converting a communications security problem into a key management problem.” Any channel can be made secure if all parties have enough key material. The implementation details of getting those keys around, making sure that the right people have the right keys, and so on, are the details in which the devil lives. But these details matter, and as mobile messaging is a part of everyday life, it’s important that the workings are transparently presented to the users. This talk does a great job on the demystification front.

An interactive console program that allows traffic flows to be intercepted, inspected, modified and replayed.

https://mitmproxy.org/

Fast-forward to the end of the talk, and you’ll hear someone in the audience ask [Ray] “Are there any Bluetooth locks that you can recommend?” and he gets to answer “nope, not really.” (If this counts as a spoiler for a talk about the security of three IoT locks at a hacker conference

Unlocking a padlock with your cellphone isn’t as crazy as it sounds. The promise of Internet-enabled locks is that they can allow people one-time use or limited access to physical spaces, as easily as sending them an e-mail. Unfortunately, it also opens up additional attack surfaces. Lock making goes from being a skill that involves clever mechanical design and metallurgy, to encryption and secure protocols.

Relive: Lockpicking in the IoT
http://streaming.media.ccc.de/33c3/relive/8019

New Leet Botnet Shows IoT Device Security Regulation May Become Necessary

Just before Christmas, Imperva found its network under a massive DDoS assault that reached 650 Gbps (Gigabit per second), making it one of the largest known DDoS attacks on record.

Powered by what Imperva is calling the Leet Botnet, the attack occurred on the morning of Dec. 21, and was delivered against several anycasted IPs on the Imperva Incapsula network.

While precise device attribution is not yet possible, it seems likely that, like Mirai, it uses thousands of compromised IoT devices.

“Due to IP spoofing, it’s hard to accurately identify the devices used in this attack,” Avishay Zawoznik, security research specialist for the Incapsula product line at Imperva, told SecurityWeek. “We did, however, find some reliable clues in the payload’s content. Here, manual analyses of individual payloads pointed to some type of Linux device. For instance, some were ‘stuffed’ with the details of the proc filesystem (/proc) folder, which is specific to Unix-like systems.”

Hidden behind spoofed IP addresses, it was impossible to locate the geographical location of the attacking devices; but Imperva was able to analyze the content of the packets being used. Although similar in size to the Mirai attack on KrebsOnSecurity in October, it was immediately clear that this was different. (There have been some suggestions that the Mirai attack against DNS service provider Dyn could have exceeded 1 Tbps.)

Leet’s name comes from a ‘signature’ within the packets. “In the TCP Options header of these packets, the values were arranged so they would spell ’1337′. To the uninitiated, this is leetspeak for ‘leet’, or ‘elite’,” notes Imperva.

Two separate payloads were used: regular SYN packets (44 to 60 bytes), and abnormally large SYN packets (799 to 936 bytes). The content of the large packets was taken from the compromised devices and scrambled. The result is an inexhaustible supply of obfuscated and randomized payloads that can bypass any signature-based defenses that mitigate attacks by identifying similarities in packet content.

There is no immediate solution beyond preparation as far as possible. “Organisations should be prepared to mitigate DDoS attacks and be prepared to get back up and running once the attack is over,” suggests F-Secure security advisor Sean Sullivan. “DDoS attacks cannot be prevented; being prepared to reduce downtime in the aftermath lessens the threat of DDoS. Extortionists will move on to weaker targets that are less prepared.”

In the short term, warns Sullivan, “There’s little hope that networking and IoT equipment will become more secure, although ISPs could empower their security teams to run cleaner networks.”

Apparently, frustrated users complain more often recently on various forums about their embedded devices being overloaded with computing and network tasks. What these particular posts have in common is the name of the process causing the problem. It is executed from a temporary directory and disguised as a part of the Java framework, namely “.javaxxx”. Additional names like “.swap” or “kworker” are also used. A few weeks ago, we discussed the recent Mirai incidents and Mirai-connected IoT security problems in The Hive Mind: When IoT devices go rogue and all that was written then still holds true.

The Hive Mind: When IoT devices go rogue
http://www.welivesecurity.com/2016/10/26/hive-mind-iot-devices-go-rogue/

The Internet of Things (IoT) has been referred to by so many different names in the past year: The Internet of Terror, the Internet of Trash and a few other catchy monikers to account for the large amount of vulnerabilities present in new devices that are increasingly present in many homes.

Attack vector

The attack is performed via brute force attempts at SSH logins, in a similar way to that in which many Linux worms operate, including Linux/Moose (which spread by attacking Telnet logins) – also referenced here – as analyzed by ESET since last year. The targets include both embedded devices and servers with an open SSH port and where a very weak password has been set. The obvious aim of this trojan is to assemble a list of unsecured devices and to have an opportunity to create a botnet consisting of as many zombies as possible. The scan starts with not too extensive list of IPs and spreads incrementally to more targets. Only machines that represent low-hanging fruit from the security perspective are compromised. Note that victims reported cases when they had had a strong password but they forgot their device that had online service enabled and it was reverted to a default password after a factory reset. Just a couple of hours of online exposure was enough for such a reset machine to end up compromised!

Vulnerabilities of Embedded Systems
Embedded systems are vulnerable to assault for a number of reasons, the chief ones being their connectivity, accessibility and low availability of resources to support security and authentication.

It is estimated that by 2020, there will be 28 billion embedded systems connected to the internet. With greater connectivity comes an increased risk of being attacked. Every communication node becomes a potential weakness. Failure of any one embedded system can create cascading events that, in extreme cases, can bring down entire networks – say, a bank’s ATM machines or a power grid.

Cryptography Suited to Low-Resource Embedded Systems
One of the hurdles to effective encryption is the limited resources available in embedded systems. While devices with adequate power supplies and computing resources, like PCs, can run security protocols rapidly, embedded processors, which have far less power and processing capacity, take longer. Because of the systems’ small processing capabilities, some cryptography researchers have proposed hardening them with ECC protocols.

Our benchmarking and recent publications show that ECC has several drawbacks in securing low-resource devices like embedded systems. For example, the 8- or 16-bit processors typically used in embedded systems do not have the resources to run ECC for authentication, identification and data protection in short timeframes.

SecureRF’s cryptographic solutions for embedded systems are based on Group Theoretic Cryptography. They run up to 63 times faster than ECC while using less than 1% of the power ECC requires, and are quantum-resistant.