Application and Cybersecurity Blog | Security Innovation
Security Innovation is a global provider of application security & cryptography solutions. The company helps build internal security expertise, reduce application risk, and improve the process by which applications are built.
How to Positively Use Compliance Mandates to Drive your Security Standards
Seems like every year there’s a new/modified cybersecurity regulation, standard, or compliance framework that thrusts itself to the forefront of our collective psyche. This year, that clearly was GDPR. While the semantics of each vary, the premise (protect data) and overlapping controls are very similar.
The table below is not meant to be comprehensive, but to illustrate this.
Privacy and integrity of financial data in publicly traded corporations
Ensure confidentiality, integrity, and availability of all electronically personally identifiable information (ePHI)
Confidentiality of payment card information stored and used by merchants
Data protection regarding privacy and personally identifiable information for all natural persons in the European Union (EU)
The Corporate Application Compliance Framework
With the right knowledge and planning, meeting the application-driven requirements is easier than most organizations think. This can be accomplished by:
Align development processes to implement specific secure coding practices that align with corporate policies and compliance requirements
Create an action plan to address gaps between current secure coding practices and the desired ones
Development groups typically concentrate on delivering functionality and meeting schedules because they perceive that management priorities place these goals far ahead of application security and compliance.
To counteract this tendency, teams need guidance from management on topics such as:
The importance management places on data security and compliance
The direct impact software applications have on data security risks
The business implications of not meeting compliance mandates
In other words, enterprises need an explicit process for translating compliance requirements into actionable steps for IT teams. Because there are few resources for this, I suggest the Corporate Application Compliance Framework, illustrated below.
At the top level, the enterprise risk management (ERM), human resources and legal groups define the global scope and requirements for corporate governance. These are based on company mission, risk tolerance and regulations affecting the organization.
At the middle level, an ERM group, together with representatives of the compliance and security teams, take the corporate security and compliance standards and add detail to create security policies for the company. These are high-level guidelines for operational security and compliance activities that can later be contextualized for specific business units and functional roles.
Typical tasks at this level include:
Keep abreast of applicable regulations and standards
Conduct a threat assessment to determine the security breaches potentially most damaging to the enterprise
Classify data assets to define levels of data sensitivity and identify which business processes store and transmit sensitive data
Define concrete application security objectives
At the base level, the security and compliance teams help define specific practices for documenting compliance and ensuring they address business-unit-specific regulations and technologies. Standardized practices improve consistency, reduce errors, and facilitate testing. Most importantly, they provide a benchmark against which compliance can be measured.
“Connecting these dots” requires a range of experts to pool their knowledge to triangulate between:
Applicable regulations and standards
Probable threats and application-related vulnerabilities
Application security techniques and coding practices
While coding standards/best practices can vary, the following table summarizes the more important, grouped by high-level requirements.
Corporate Application Compliance Framework
Selected Coding Practices
SOX, PCI DSS, ISO 27002, HIPAA, GLBA, FFIEC, Basel lI, CA SB 1386, FIPS, NIST SP, GDPR
· Do not use custom or untrusted encryption routines
· Always encrypt confidential data at rest and in motion
· Use security approved and well tested cryptographic APIs
· Mask confidential data that needs to be viewed in part; anonymize data when possible
· Collect and store only the minimal set of data needed
· Use a strong encryption algorithm with appropriate key length
· Encrypt your backups and secure the encryption keys
SOX, PCI DSS, ISO 27002, HIPAA, GLBA, FIPS NIST SP, GDPR
· Robust integrity checks to prevent tampering with data
· Validate all input and encode all input and output
· Follow least privilege principle
· Hash confidential data that needs to be validated (e.g., passwords) with a modern hashing algorithm
Authentication and access control
SOX, PCI DSS, ISO 27002, HIPAA, Basel, NIST SP
· Implement policies that enforce strong password, password expiration, inactivity timeouts and two-factor authentication
· Locked-down role-based access control with clear roles mapped to permissions. Revoke rights when roles change
· Securely store and transmit authentication credentials
· Do not enable or provision for “guest” accounts
Logging and Auditing
SOX, PCI DSS, ISO 27002, HIPAA, GLBA, NIST SP, GDPR
· Detailed audit trails of users/apps accessing data and resources
· Detailed logging on systems that process sensitive data, including shutdowns, restarts and other unusual events.
· Event logs and audit trails are available only to system admins and are resistant to tampering
· Do not log any sensitive data
· Create a consistent error handling architecture that is used throughout your application
· Use generic error messages that do not reveal sensitive information to the user.
SOX, ISO 27002, HIPAA, Basel II,FIPS 199, NIST SP, GDPR
·Failover and redundancy built into applications
·Applications resistant to denial-of-service attack with build in throttles and Turing test controls.
· Cleanup confidential data in memory and in file systems when it is no longer needed
· Don’t fail to an insecure state
· Create Business Continuity and Disaster Recovery plans for the application and test them regularly
· Backup data
SOX, Basel II, NIST SP
· Source control
· Document all changes to the application
· Secure access to source code and check-in rights
· Implement a code review process where all modifications get validated by peers
· Regularly review code and systems changes and their impact with stakeholders
·Create an architecture that you can quickly deploy and roll-back changes in production
·Limit deployment rights to authorized personnel
·Cryptographically sign your builds and validate integrity during deployment
·Maintain a database of "known good" configuration and regularly integrity check your systems for any undocumented deviation
While this mapping can be time consuming, the more specific and practical the guidance, the easier compliance will be achieved.
Security Innovation has the industry's largest selection of secure coding courses that map to more compliance mandates and cover all major languages and platforms.
According to a recent Gartner report, it is estimated that 20.4 billion connected “things” will be in use worldwide by 2020. There are already twice as many devices connected to the internet than there are people on our planet.
The concept of IoT and IoT security is no longer new. I am sure, terms like "Hardware Security”, "Machine-to-Machine Security", "Connected Device Security", and "Embedded Device Security" ring a bell. While they all have slightly different connotations, these terms all refer to the same concept of an embedded device that is network enabled and part of the growing Internet of things, connected world. IoT forms the basis for some of the most prevalent devices we use in our day-to-day life: smart watches, virtual assistant services, smart home devices and many more.
There are 2 primary components of any IoT system:
Hardware Devices that users use (the "Things"). The main purpose of the device is to provide the user with an interface that they can interact with.
Back-End Components that the devices communicate with and perform the lionshare of data aggregation and processes.
There are various attack vectors that can be used to compromise an IoT device:
Firmware Running on The Device
As device manufacturers grapple with time to market pressures, vulnerabilities will not be discovered until after release. Most organizations do not have a proper patch management process in place. If the firmware updates are not cryptographically signed and sent over a secure channel, there is no way of identifying if the firmware was modified before being flashed on to the device. Similar attacks would be valid for an insecurely configured boot loader or if the checks are not performed at every stage of the boot sequence.
IoT hardware components need to communicate with each other and other devices over standard protocols like I2C or SPI.
In addition to the communication protocol, the physical boards normally have ports like JTAG and UART that are used for debugging purposes. JTAG port also allows for reading/writing to the firmware post production. If these ports are active in production devices, an attacker can use tools like Jtagulator (https://www.grandideastudio.com/jtagulator/) to extract the existing firmware, reverse engineer its functionality or to flash a newly modified firmware.
Device Radio and Network Communication
Wi-Fi and Bluetooth configurations present major security challenge when trying to secure IoT devices. The attacks could be based off weak configurations or discovery modes. Lack of Transport Encryption exposes data in transit to tampering by parties that can execute Man-in-the- Middle (MitM) attacks.
For IoT systems, such data can include authentication credentials, session identifiers and other tokens, and private user information. The attacker might also be able to tamper with unencrypted communications in order to alter device behavior, for example, changing the temperature on a networked thermostat.
Radio interface has also become an increasingly common attack surface on many IoT devices. NFC, RFID, Zigbee, Z-Wave are some well-known examples. Though relatively newer, an attacker can use a variety of tools to sniff, intercept and modify these radio protocols.
Mobile, Web and Other Back-End Interface
The back-end interface is often the most exposed and vulnerable component of an IoT solution. Attackers can use the same tools and techniques to attack them as they have been using to attack other web applications. Weak local encryption, hardcoding of passwords and a lack of secure password policy is far too common and a very lucrative attack vector.
Strong authentication and authorization are absolute essentials for securing an application domain, especially the Internet of Things. It is a common authorization error to assume that methods on the IoT devices that do not have a calling UI element will not be accessible by that user. Under this false assumption, users may be able to access sensitive information or secure functionality once it is discovered. This can be done by means of tools like Burp Suite (https://portswigger.net/burp) or Mallory (https://github.com/intrepidusgroup/mallory).
The IoT device is only as secure as the hardware and software components that it is made up of. To help enterprises secure against the known and the unknown IoT attack vectors out there we have come up with a Tipsheet that can help gauge the current state of security for their IoT devices better.
Be Sure to Check Out All of Our Resources on Our Website Too:
I went to the very first Internet of Things (IoT) meet-up in New York City five years ago when the term “digital transformation” was just starting to become a buzz phrase and IoT devices were appearing everywhere. It was then that I realized the impact all those interconnected “things” would have on cybersecurity.
Devices before IoT where just that, devices. They ran on code and were made to solve a specific purpose. It could have been to program your thermostat, a garage door-opener or an EKG machine. Now all of these devices are interconnected. If you want your thermostat to change to a warmer setting as you pull your car into your garage, that is now possible. All of our devices are conveniently connected and able to communicate with each other either via central control systems or with some consumption device like your phone or tablet. Getting too hot? Just have your thermostat signal your blinds to close. Speak into your phone and have your front-door unlock. Washing machine in need of a check-up? It can request service by itself through an API call.
Realities of Modern Convenience
Sure, we call this modern consumer convenience, but it is also very convenient for an attacker. As more and more devices are connected, the attack surfaces infinitely increase and therefore vulnerability potential increases.
Some consumers may not find this concerning. “What is an attack surface anyhow,” they may ask? And manufacturers may be more concerned with getting products out to market before even considering the potential vulnerabilities that live in their products. Why would someone want to mess with your thermostat, your blinds, or read your EKG? Until we hear about what it could mean when someone hacks into our devices: maybe it's your baby monitor and scaring your family with weird noises and threats or what if someone hacked into and turned off your pacemaker, then we suddenly realize the potential.
Why is Securing IoT Devices So Different?
So how is securing these devices different than securing other devices such as desktops, servers and cell phones? Attackers hacking into devices with vulnerable code is not new. So, what is different with IoT and why is it hard to secure these devices?
There are multiple factors at play here, let’s look at some of them:
Failing To Completely Understand The Risks
Manufacturers always want to be first to market, launching the latest device but failing to understand the true security risks that these devices may hold. This means that in a race for functionality, some security defects may be overlooked. Often consumers do not understand the security risks of these devices and thus, do not hold the manufacturers responsible for these risks. I have heard a personal EKG device manufacturer say “I don’t think anyone would care to hack our device,” and a potential consumer in the same setting back them up.
When “things” are attacked, it is difficult to detect the attack and ultimately place responsibility on the manufacturer. After all, if Windows® crashes, resulting in the loss of a days’ work, it is easy to blame it on Microsoft®. However, if a Wi-Fi router is being used by attackers to mine Bitcoin, it may be using a bit more electricity, but is likely unnoticeable to a consumer.
Ease of Set-up and Authentication
Deployment of IoT devices has inherit security flaws as well. Typically locking down a device by setting a secure password or installing security keys for communication requires some work on the consumer side. However, these devices are designed to be installed as easily as possible, with minimal to no configuration. Unfortunately, this means that default passwords are hard-coded into the devices, insecure communication protocols are used, and the most lax permissions are selected.
Lack of Patch Management
Finally, when vulnerabilities are discovered in servers, desktops or phones - they are patched. Patches are distributed and installed on the affected systems. Patch management however, becomes more difficult in embedded devices. Here, patching mechanisms either do not exist, or are poorly implemented. Sometimes patching may not even be possible. While you can update a Windows machine with some downtime for a reboot, rebooting a pacemaker is probably not in the best interest of the user.
Working Towards Better Secured IoT Devices
These reasons and more are what make the IoT world so lucrative for attackers and so difficult for security practitioners. Nevertheless, this does not mean that we should just give up. There are ways of making IoT devices both convenient for the consumer and secure from attacks. It just requires a little effort and rigor.
Given the proliferation of software, limited resources, and the constant stream of breaches, organizations continue to seek ways to implement high impact activities to reduce enterprise risk. Although this can be achieved by conducting a variety of analysis and testing techniques, it is important to focus on those that address your most critical threats and nightmares - those that can ultimately bring an organization to its knees, like theft of IP or failing medical device (versus defacing of web site, loss of funds, etc.)
At Security Innovation we are fascinated by the prospects of Blockchain technology. Whether it be in finance, commerce, Internet services, or any of the other applicable sectors, we are excited by the potential for Blockchain to provide new efficiencies and disrupt existing models.
New applications of Blockchain technology are being researched and discovered each day. For companies that are investigating use cases of this exciting new technology, it is more important than ever that security be their top priority. Since the consequences of an insecure Blockchain application will often result in immediate financial loss, it is critical that developers of blockchain applications are fully prepared to identify and prevent common vulnerabilities in these platforms.
Distributed Apps (DApps)
One specific area we are most interested in is the use of programmable smart contracts. By writing front-end web applications called DApps (Distributed Apps) that interact directly with smart contracts, users will be able to conduct commerce in a new decentralized fashion never before possible.
With any new technology comes new threats as well. With smart contracts in particular, the risk of deploying a vulnerable contract is even more pronounced by the ease in profiting from a successful exploit. Additionally, due to the immutable nature of these contracts, ensuring vulnerabilities are prevented before deployment is all the more crucial.
Holding Software to a Higher Standard
One of the principles we hold dear at Security Innovation is to do the most good. We do this primarily through education and spreading security awareness. When it comes to security, we see it as our mission to hold software to a higher standard.
With that in mind, we are excited to announce the release of our new free interactive platform to help others learn about smart contract security, the Security Innovation Blockchain CTF.
With this platform, we have constructed a series of vulnerable smart contracts and DApps with real-life use cases, ranging from decentralized trust funds and open source lottery systems, to ICOs and automated royalty agreements. Each of these applications contain a vulnerability commonly found in smart contracts. Participants can practice exploiting these bugs to steal fake crypto-currencies and win points on our leaderboard.
As with our CMD + CTRL cyber range offering, where we have brought gamification to actual live web applications for an engaging learning experience. Throughout Blockchain CTF we provide helpful hints and resources that assist users in learning more about the tools and methodologies used when developing, testing, and using DApps and smart contracts.
In the spirit of decentralization, we have developed the platform as a client-side DApp with our smart contracts running on the Ethereum Testnet Blockchain. This means that there is no back-end server components aside from a few statically hosted scripts. All state is managed by the permission-less, decentralized network running the Ropsten Testnet Blockchain.
TRY SI BLOCKCHAIN CTF
We are excited to be publicly releasing this project so that developers and testers everywhere can learn more about this exciting new technology and ensure that security is at the forefront of their efforts. Click on the button below to start playing.
You will need the following set-up to play or view the leaderboard. Install the tool Metamask. It's an extension you can install to most browsers. You can get it at the following URL: