Year: 2016

Segregation of duties (SoD) has been a source of guidance for audit and accounting systems for a long time; nevertheless, many IT security controls imposed by recent trends and regulations can be viewed through its lenses.

Privacy by design and privacy by default, for example, as required by the new EU regulation recently approved by the European Parliament, require that duties are well separated and roles are well defined from the beginning.

Privacy by design must be introduced in the design of processes and in the design of systems and tools. For example, a client recently asked for a solution to make service desk personnel able to reset user passwords without knowing the user’s new password and without resorting to the self-help password reset. This does not only require a supporting tool but also a sound access management process in which SoD is the central issue.

On the market side, the segregation between development and operations functions blurs with the widespread adoption of movements such as Development and Operations (DevOps), but SoD must still be achieved. This can be obtained by properly differentiating duties, e.g., responsibilities of the different environments (development, test, production).

Enforcing controls by means of the appropriate tools is an important issue, and it may lead to higher levels of segregation. For example, for a long time the common practice has been to use (masked) data from the production databases in the test environment; now, some tools are available that synthetize artificial test data to be used in the test environments. Such tools guarantee better coverage and enhanced privacy and effective segregation between environments. This helps test data and production data remain separated, and responsibilities of the test and the operations teams remain separated as well. Segregation encompasses data in addition to duties in this case.

New technologies, new regulations (e.g., EU’s data protection regulation, the ISO 25000 family of standards on data quality) and new trends such as DevOps introduce new requirements and new risk.

SoD can be used within a consistent risk assessment framework, e.g., COBIT® 5 for Risk, both as a security control and as a magnifying lens that can help spot IT risk.

Read Stefano Ferroni’s recent Journal article:
“Implementing Segregation of Duties,” ISACA Journal, volume 3, 2016.

Stefano Ferroni, CISM, ISO 27001 LA, ITIL Expert

[ISACA Journal Author Blog]

Malware can be challenging to remediate because it comes in an endless number of varieties and a wide range of threats, including low-end scareware, medium-level ransomware, to high-level advanced volatile threats (AVTs) and advanced persistent threats (APTs).

Ransomware made the news recently and has become a concern. This sort of infection often starts with a single user and then expands to any drives that user has access to. Once infected, ransomware can end up overwriting very important files, especially if the user has access to a company shared drive.

For retail organizations, point of sale malware has also been very common in recent years. We have seen breaches at many major retailers and will likely continue to see breaches in the future. This sort of malware scrapes the memory of the point of sale systems looking for data that matches the pattern of credit card numbers. The credit card data is then extracted from these systems and sold or utilized in fraud.

Sophisticated APT attacks are conducted by stealthy, well-resourced, well-researched, dogged adversaries intent on gaining a foothold into an organization’s IT infrastructure.

AVTs More Potent Than APTs
Then there are AVTs, which are malware that are not written to disk. Very sophisticated attackers exploit a process or service, carry out their malicious actions in the memory space of the exploited process, and then delete themselves, leaving no forensic evidence on the hard disk. AVTs do not have to reach the victim’s hard drive to deliver their payload. Traditional antivirus solutions depend on the presence of a file on the hard drive, so no evidence of malware on the hard drive makes AVT attacks more potent than the related APTs.

Malware is a business though, and most malware authors would rather stay on your computer for an extended period of time. This means that malicious programs generally save a copy of themselves to disk so that when the computer is rebooted it can start running again. There is an interesting category of AVT malware called memory-only malware. This malware resides solely in memory, thereby evading detection by the aforementioned traditional antivirus software solutions, which scans files on disk.

Creative methods have been found to achieve persistence (restarting after reboot) in memory-only malware. The most well-known in the memory-only malware family was Poweliks. This malware stored itself in the Windows registry and had some code to reload and execute that registry entry each reboot. Other pieces of malware, such as the Linux/Cdorked, featured a modified Apache binary but stored most of its code in shared memory. Since most of its logic was stored solely in memory, it was a challenge to analyze.

Controlling Malware Threats
An in-depth security policy is your best defense, including having your network and end points protected, proper access controls and network segmentation. With all of that in place, one major aspect that is often overlooked is user education. Suspicious users can save organizations a lot of money. This could cover everything from browsing habits and being wary of advertisements, all the way to suspicion of emails and phone calls. We have seen many phishing and social engineering attacks that impersonate executives and trick employees into revealing banking details or transferring money to a fraudster. A well-educated user is going to think twice before clicking a link in their email or giving away information on a phone call.

Evolution of Threats and Controls
Organizations are plugging more and more devices in and hooking them up to the Internet. From security systems to ovens, everything is “smart” and connected now. This interconnectedness brings complexity and risk. One improperly configured device or incorrect line of code can have disastrous effects. It would not be the end of the world if someone exploited your refrigerator and mined Bitcoins on it, but when organizations start hooking up medical devices and vehicles to the Internet, careful consideration needs to be given to the implications of doing so. Organizations need to ensure that the systems being built are secure.

Note:  ISACA Now is running a series of blogs on the 10 threats covered in ISACA’s Cybersecurity Nexus (CSX) Threats & Controls tool. The threats include APT, cybercrime, DDoS, insider threats, malware, mobile malware, ransomware, social engineering, unpatched systems and watering hole. To learn more about the controls for cybercrime, as well as recent examples and references, typical patterns of cybercrime and more, visit the tool here.

Douglas Goddard, Analyst, Independent Security Evaluators

[ISACA Now Blog]

We hope this blog provides an insightful dive into topics like cloud computing, managed services, products, and ways to improve your business strategy. Of course, our partners have great things to say, as well. One of those partners is AWS, and they’ve been kind enough to highlight the most popular security posts on their blog from the past year. There is some great info here; below is our take on just a few of these posts.

Privacy and Data Security
Security has always been a concern for the enterprise. Initially, it was a major barrier to entry for migrating to the cloud, but over the past few years, a greater number of businesses have realized that, like us, AWS takes security very seriously. This post talks about some of the best practices of the company.

Perhaps the biggest is protecting the privacy of its customers. AWS doesn’t disclose customer information unless required to do so to comply with a legally valid and binding order. And, if they do have to disclose information, they’ll notify customers beforehand. AWS also offers strong encryption as one of many standard security features, and gives organizations the option of managing their own encryption keys. That’s one of the driving forces behind our Datapipe Access Control Model for AWS(DACMA) offering – you get to hang onto the keys to your system, and maintain complete control of your virtual infrastructure and your data. What’s more, DACMA requires two-factor authentication, and all system access and activities are tied back to unique user names, without the hassle of managing an exhaustive list of AWS users. This added layer of security and accountability ensures your business is protected and meeting compliance requirements.

Receiving Alerts
It’s never a bad idea to have an extra layer of security within your infrastructure. As an AWS administrator, you can be notified of any security configuration changes. Changes are to be expected, but if anything seems out of the norm, you can make sure no changes to your AWS Identity and Access Management (IAM) configuration are made without you being made aware.

This post from AWS goes into detail on some of the steps you can take to stay in touch with all that’s going on within your AWS structure. From using CloudWatch filter patterns, to monitoring changes to IAM, to generating alarms and metrics, these are all necessary to ensure nothing gets by your watchful eye. Once everything is set up, you’ll receive an alert via email or SNS topic. The below image illustrates the process:

PCI Compliance in the AWS Cloud
Payment Card Industry (PCI) compliance is important for just about any business. However, one of the more complex aspects of cloud hosting is deciding which party is responsible for PCI requirements. ThePCI Compliance workbook provides a guide on where AWS can cover compliance requirements, and which areas a business must cover itself.

There are twelve top-level PCI requirements in all, and they are quite complex. It can be easy to miss certain requirements or not stay up to date with audits. It’s important to note that you can’t just arbitrarily ignore a PCI requirement—all of them must be met. It may be possible that not all requirements apply to your business, so a PCI assessor is helpful for clarifying which do and do not apply. We were one of the first hosting providers in the world to achieve PCI DDS Level 1 service provider status—the highest, most rigorous status in the industry—and are happy to work with enterprises to ensure they’re setup and maintain their AWS environment compliance.

As a business, it’s refreshing to know your provider has your best interests in mind. For more information, check out our previous posts on AWS security.

David Lucky, Director of Product Management, Datapipe

[Cloud Security Alliance Blog]