Day: September 16, 2016

Contributions from Six Dedicated Individual CSA Volunteers Recognized in Honor of the Late CSA Member and Volunteer Contributor Ron Knode

SAN JOSE, CA – CSA Congress US – September 15, 2016 – The Cloud Security Alliance (CSA), the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment, today announced the recipients of its fifth annual Ron Knode Service Award, recognizing six members from the Americas, Asia-Pacific and EMEA regions for their excellence in volunteerism. The honorees were selected by the CSA executive team and chosen based on their valuable contributions towards fulfilling CSA’s mission of promoting best practices to help ensure a secure cloud computing environment.

Ron Knode was an information security expert and member of the CSA family who passed away in May 2012. He is remembered as an innovative thinker with endless energy and humor to guide his volunteer contributions. He also was the creator of the CSA Cloud Trust Protocol, which today remains an important asset for the continuous monitoring and auditing for cloud assurance and transparency certification. Established in 2012, the Ron Knode Service Award is awarded to CSA members on an annual basis whose contributions reflect Ron’s passion for volunteerism and embody the spirit for which this award was established.

“The six individuals that we are recognizing today epitomize Ron’s spirit of tireless efforts and commitment to volunteerism. In his honor, we congratulate and thank them for their vast commitment to promoting and defining best practices in the cloud to help ensure a secure cloud computing environment globally,” said Jim Reavis, CEO of the CSA. “We will always remember Ron’s energy, humor and incredible generosity. CSA is grateful for his hard work and dedication, and we continue to benefit from his commitment and passion.”

This year’s six recipients are:

Juanita Koilpillai, CSA Americas: Juanita Koilpillai is the Founder and CEO of Waverley Labs, elevating IT Security to C-level executives and managers to ensure on-line business processes are trusted and helping small technology companies develop their product potential. She is a member of the CSA Software Defined Perimeter Working Group and contributed to Spec 1.0 and 2.0. She is currently leading the open source software defined perimeter effort after securing funding from DHS to launch the effort specifically for distributed denial of service attacks, with the first version of the open source software defined perimeter now available to the CSA members. Juanita presented “An Open Source Software Defined Perimeter” at the Cloud Security Alliance Federal Summit in May 2016 and at the Berlin Conference in November 2015.

Brian Russell, CSA Americas: Brian Russell is a Chief Engineer focused on Cyber Security Solutions for Leidos. He oversees the design and development of security solutions and the implementation of privacy and trust controls for customers. Brian leads efforts that include security engineering for Unmanned Aerial Systems (UAS) and Connected Cars, the design of secure next- generation energy systems (microgrids) and the development of high assurance cryptographic key management systems. He supports the Center for Internet Security as a member of the 20 Critical Security Controls Editorial Panel and represents the Cloud Security Alliance (CSA) on the FCC Technological Advisory Council on IoT. He also serves as Chair of the CSA Internet of Things (IoT) Working Group and lead author of the report ‘Designing and Developing Secure IoT Products’ and the ‘Practical Internet of Things (IoT) Security.’

Anthony Lim, CSA APAC: Anthony Lim is the Director of Marketing Strategy for Asia Pacific at Cloud Security Alliance and an independent cybersecurity professional services consultant, advocating, researching, lecturing and auditing various cloud security and smart cities opportunities. He has led various initiatives and activities at CSA including speaking at numerous seminars and conferences in Asia Pacific in 2016 and acting at the first CCSP instructor in Asia Pacific. He previously was on the Board of Directors for CSA’s Singapore Chapter, was a member of the CSA-ICS2 JTA committee that build the CCSP, chaired Trend Micro at CloudSec 2016. Anthony has also appeared on several TV news shows representing CSA including Singapore Chinese Channel and the BBC.

Eric Wang, CSA APAC: Eric Wang is the current CEO of TanoSecure Inc., a holding company supporting emerging technology companies founded by visionaries in the ICT industry. He currently serves as the cybersecurity advisor to the Taiwanese government and has played an instrumental role in the development of multiple technology start-ups. He is the current Co-Chair of the CSA Mobile Application Security Testing Working Group leading efforts on the design and development of a mobile application development certification program.

Bruno Huttner, CSA EMEA: Bruno Huttner is the Product Manager for Quantum Key Distribution Products at ID Quantique, where he develops next-generation encryption, and especially quantum key distribution systems. He is also responsible for a project aimed at providing secure communications with satellites and high altitudes platforms. Bruno is Co-Chair of the Quantum-Safe Security Working Group at the CSA. Leading the group over the past 18 months, he has contributed heavily to the four papers published from the working group. He has been very active at various conferences, including presenting the Safe Security Working Group material at numerous CSA events. Bruno has also participated in CSA’s EMEA Congress in Berlin last year and RSA in San Francisco this past March, where he organized and chaired a panel session.

Andreas Fuchsberger, CSA EMEA: Andreas Fuchsberger is the Regional Standards Officer for Central and Eastern Europe in Microsoft’s Corporate Standards Group. Andreas participates in the internationalal standards community, predominantyly attending ISO/IEC JTC 1/SC 17 (Security) as an invited expert. Currently for SC 27 he is the editor of two international standards on network security and SIEM. He is a member of the (ISC)2 Application Security Advisory Board where he also chairs the International Standards Committee. He Co-Chairs the CSA Internatiional Standards Councils where he is liaison officer to ITU-T SGs 13 and 17 and chairs the CSA’s Open Certification Framework (OCF) working group.

About Cloud Security Alliance
The Cloud Security Alliance (CSA) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment. CSA harnesses the subject matter expertise of industry practitioners, associations, governments, and its corporate and individual members to offer cloud security-specific research, education, certification, events and products. CSA’s activities, knowledge and extensive network benefit the entire community impacted by cloud — from providers and customers, to governments, entrepreneurs and the assurance industry — and provide a forum through which diverse parties can work together to create and maintain a trusted cloud ecosystem. For further information, visit us at www.cloudsecurityalliance.org, and follow us on Twitter @cloudsa.

Contacts
Kari Walker for the CSA
ZAG Communications
703.928.9996
kari@zagcommunications.com

[Cloud Security Alliance Research News]

One of the objections I’m hearing more and more is, “Why do I need backup when I have Microsoft OneDrive for Business (or Google Drive, Box or Dropbox for Business)?” On the surface, it may seem like endpoint backup isn’t needed because with an enterprise file sync and share (EFSS) tool, a copy of the data is in the cloud. But if you dig a bit below the surface, you’ll find there are several distinct differences. We cover those in our Top 3 Iron-Clad Reasons Why File Sync/Share is Not Endpoint Backup, so I won’t go into them here.

Instead, I thought I would illustrate a situation in which it’s painfully obvious why it’s important to have modern endpoint backup. Every organization today is facing ransomware. No matter how sophisticated your defenses, ransomware invariably finds a way through.

For example, Jeff, a recruiter from the Human Resources team, is reviewing resumes to fill a new position. He receives an email with a link to download a resume in Microsoft Word. As part of his process, he downloads the resume to his OneDrive “Job Postings” folder which is shared with his HR co-workers. The document is automatically uploaded to OneDrive and synchronized to his co-workers’ devices.

Unfortunately, this is no ordinary resume. It contains a crypto-ransomware. When Jeff opens the resume, the ransomware takes hold and begins encrypting the files on his local device as well as network shares. Because Jeff saves a lot of files in his OneDrive folder, as the ransomware encrypts those files, OneDrive then syncs them to the cloud. And for any shared/team folders he has, the encrypted files are synced to his co-workers as well as to any publically shared files/links. And even though Jeff is supposed to save all of his files to OneDrive, he keeps a bunch on his desktop where he likes to work. He’s also got a big .PST email archive sitting on his device as well. All of those files are being encrypted by the ransomware to lock out access.

Because Jeff saved the file to a shared HR folder, the ransomware file now appears on his co-worker Julia’s laptop. Julia takes a peek at the resume and now the ransomware starts attacking her device.

At this point, Jeff tries to open one of his files and gets the dreaded ransom note. For just one bitcoin, he can get his data back. He contacts the help desk to let them know what happened and get help. OneDrive keeps previous versions, so no problem, right? Help desk then informs Jeff that he can get his earlier file versions, but he has to do it file-by-file! And for those files that were saved outside of OneDrive, he’s out of luck. Next up is Julia who calls up help desk and is in the same boat as Jeff. Not only did EFSS not help with recovery, it actually spread ransomware!

Well, that’s when it becomes clear that EFSS is not a true backup solution. EFSS leaves it up to the user to pick the right spot to save his data. And when it comes time to remediate from an event like ransomware, EFSS is not equipped to handle large restores. Even EFSS vendors themselvesrecommend having a true backup of the data to recover from an event like ransomware.

Hopefully this real-world scenario makes it easier to distinguish the differences between file sync & share and modern endpoint backup—and the advantages of true endpoint backup when recovering from ransomware.

Kyle Hatlestad, Principal Architect, Code42

[Cloud Security Alliance Blog]

“Don’t just check the box!” Chances are you have said or heard this phrase at some point in your career. In case you are not familiar with the term, it refers to a mechanical, “bare minimum” way of doing things. Sometimes it means simply not being creative in your approach. As I will explain, checking the box can actually be a very good strategy to uncover problems, especially if you are in a control assurance function. More precisely, I will call my strategy “Check the boxes.”

Let me take you back to the late ’90s when I was a novice IT auditor in a multinational organization. I had just made the switch to the audit profession after having been a systems developer for a few years.

An Army of Programmers to Fix Y2K
The biggest challenge at that time was the so-called “Year 2000” (or “Y2K”) problem. Many applications in those days used a two-digit representation of the year field (“99” was used to represent the year 1999, for instance). If not remediated properly, it was feared that when the year switched from 1999 to 2000, the year field may become “00” (or something meaningless), leading to processing errors in critical systems. There was a real possibility of nuclear reactors going haywire, patients being administered the wrong dosages, and aircraft not being able to fly or land—a perfect doomsday scenario.

It took an army of programmers, testers, project managers and other IT professionals to fix systems so that no erroneous processing occurred when the date switched from 31 December 1999 to 1 January 2000.

As an auditor, I was to review the Y2K compliance of certain key applications for my organization. As part of this remit, I used to receive a package of tests and documentation from the IT owners that annotated the test results showing date-related processing. Also included was an attestation from IT and the users to certify that the system had been thoroughly tested for Y2K. Upon reviewing the documentation, the auditors made a call whether the system had shown enough readiness for Y2K or if additional documentation or clarity was needed for the scenarios tested.

First Week, Two Packages, Two Systems
In my first week on my job I received 2packages belonging to 2 different systems, which the auditors would use to perform their Y2K certification:

• System 1:  The test details came in a large brown envelope containing loose papers. Many of these showed system diagrams, test results and some handwritten comments on several computer printouts. There was no index of what was being provided. It took me several hours to ascertain the name of the system, let alone the nature of the functionality tested. For the purpose of this article, we will call this application “The Loose Leaf System (LLS).” After a preliminary review I concluded that, at a minimum, the documentation quality was poor. I could not establish for sure if the documentation was complete or accurate. This system was a winner if documentation sloppiness was the evaluation criterion.
• System 2: This documentation came in three neatly packed boxes. Inside each of the boxes were 3 to 4 labeled binders. I did not have any difficulty ascertaining the name of the system or the nature of its functionality. The first binder also had an index that clearly explained what the various binders contained. To keep matters simple, we will call this system the “Three Box System (or TBS).”

As I started my analysis of the documentation for LLS and TBS, it seemed quite obvious who was going to get top marks.

As TBS had all the hallmarks of a well-tested system, I wanted to quickly finish my review of this application first. The first binder contained an index that pointed to other binders labeled 2 through 6. As I lifted the binders to make a nice vertical stack, I noticed that there were only 5 binders in all. The fourth binder was missing. TBS had not supplied the documentation for a key piece of functionality, technically resulting in a case of incomplete documentation. When I called the IT audit manager to trace the missing binder, no one could locate it. I had my very first audit observation on my hands as a result of this discovery. The final audit result for TBS…“Failed audit” and my comment was to revise and resubmit the documentation for audit approval.

LLS also required follow-ups with its IT manager. I was, however, able to establish, to my satisfaction, that the system tests were indeed carried out and the loose sheaf of papers did contain the necessary evidence to point to a complete and accurate set of test results. Notwithstanding this, it too was a case of bad documentation quality. The audit result…“Passed audit” with minor comments on documentation.

Which System Worked Best?
Just so you are all not kept in suspense about the fate of TBS, after several weeks, I received a replacement for the missing fourth binder, as the team had to retest the functionality since they could not locate the original test documentation. During the retest, the IT manager told me they found other bugs that were not uncovered the first time around. So, my discovery of the missing binder actually helped the IT team further strengthen the TBS system.

This experience led me to coin my own principle:  “Always check the boxes”—the audit equivalent of never judge a book by its cover.

Over the years, I have found many uses for and identified several deficiencies as a result of this principle. It instilled in me the discipline to open and verify every binder, data file and artifact received from my clients. The act of thoroughly checking the boxes, or the relevant audit artifacts, has often me helped me find problems. A purist may point out that this is, after all, an application of the well-established audit dictum, Trust, but Verify. Hopefully, there is no argument over that.

Editor’s note:  Subramanian Annaswamy, CISA, CAMS, CSQA, has several years of audit experience in leading financial services organizations. He is currently a technology audit director in a leading bank in New York. The opinions expressed above are his personal views and do not represent the view of his current or former employers.

Subramanian Annaswamy, CISA, CAMS, CSQA

[ISACA Now Blog]

I understand the stress of information security management. The stakes are high, our methodologies are continuously questioned and evolving—and rightly so. And yet our customers/stakeholders/employees/executives/families wonder why we haven’t solved that whole cyber security thing yet.

My goal in this post is to highlight an area of vulnerability management that is still around the corner, for some. Think of this as a heads-up. I’ll be speaking about this topic—and releasing brand-new data from ISACA at the upcoming CSX conferences in Las Vegas, London and Singapore, in the hopes of relieving some of that stress and surprise, when what the researchers are doing now starts significantly impacting your security program.

A lot of what arrives on the desk of security and compliance managers starts in the labs of security researchers. You know, “hackers.” For those not familiar with the security research community—these are the reverse engineers, bug hunters, exploit developers and creators of penetration testing tools that raise the security bar for vendors. Finding problems is their day job.

Over the past couple of years, the security research community has been shifting gears and setting their radar on a new target: firmware. Once obscure, firmware and embedded device research is now becoming mainstream. This year at Black Hat Las Vegas, at least 20 percent of the presentations were in some way related to Internet of Things (IoT) and/or firmware security, and trainings relating to device compromise via firmware are getting more popular.

Why Focus on Firmware?
These researchers are responding to the growing numbers of systems and embedded devices powered by insecure firmware. These devices can be lucrative targets and the cost of compromise is relatively low.

Meanwhile, security and technology managers are already overworked just handling the basics: firewalls, endpoint security, intrusion prevention systems, access management, OS security; the list goes on. Solutions around firmware integrity monitoring are emerging, but many are not aware of the need.

Firmware: Easy to Pwn?
The security industry has made strides in making attacks on computers and servers more difficult; driving up the cost of attack by requiring advanced techniques to circumvent modern OS security mechanisms. Strong OS and hypervisor-level protections make systems less attractive targets, but not so much if the underlying firmware is left undefended.

There are a few fundamental reasons why firmware can make a realistic target:

• No upgrade path for firmware:  In contrast to software, firmware can be more difficult to update. Update policies may not exist; indeed, the ability to update may not even exist. Add to this the resiliency of these systems—literally devices that may sit around for decades. Changes in security requirements (e.g., updated encryption algorithms) may not be reflected in updated firmware. Even unsophisticated attack techniques are highly likely to work across outdated security mechanisms.
• Traditional methods don’t apply or can be side-stepped:  No matter how many layers of security are built into the OS, ultimately a system relies on the underlying firmware to boot and interact with hardware. Once firmware integrity is compromised, the other layers of protection may as well not exist. Attackers can bypass sophisticated security measures by directly targeting the firmware, which gets unfettered access to device functionality.
• Breaches are hard to detect:  Traditional protection systems do not monitor firmware integrity.
• The new Advanced Persistent Threat (APT):  Once a breach is detected, it is difficult to remediate. Malware can be cleaned up with antivirus or sandboxed on most systems, but a firmware compromise can persist and hide malicious behavior for months and years. Compromised firmware can also allow OS-level attacks to recur even after normal remediation actions are implemented.

The Internet of Firmware
Traditionally, firmware is associated with the BIOS on a PC, but embedded devices (a.k.a. IoT) rely on firmware in several of their components. We are not used to thinking of these new types of devices as miniature computers that need the same care in deployment, management and protection as our servers, computers and mobile phones. And they are out there by the billions: Not just in newfangled “smart” kickstarter projects for the home, but in mission- and life-critical devices used in factories, power plants, medical equipment and point-of-sale systems.

What to Do?
The role of firmware—across servers, network devices, mobile devices, storage systems, network devices and the IoT creates an abundance of targets that are coupled with surprisingly low barriers to entry for attackers. If an attacker owns the IoT, they own the future fabric of our existence.

So, this new area of focus for researchers is not a trend that will be changing any time soon. As firmware-based vulnerability moves from theory to reality, how is this scenario affecting what plays out in the enterprise? How is it addressed by compliance frameworks? How do we address these risks?

I hope you will join me as I continue to explore this topic at CSX 2016 North America 17-19 October in Las Vegas, CSX 2016 Europe31 October- 2 November in London, and CSX 2016 Asia Pacific 14-16 November in Singapore.

Editor’s note:  Justine Bone will be a keynote speaker at all three CSX 2016 conferences, presenting Mind the Gap: Analyzing Cyber Security Controls that Few Organizations are Implementing, and Why. An information technology and security executive with technical background in software security, risk management, information security governance and identity management, Bone spent more than 15 years working in the private sector for financial, news and information security companies, plus several years serving the intelligence community.

Justine Bone, Director and CEO, MedSec

[ISACA Now Blog]

In my previous post, The Demand For Talent: Hidden Risks to Security Professionals, I wrote about the highly publicized demand for security professionals along with the lesser-known risks that come with it.

While there are more opportunities for security professionals than ever before, it is important to understand why this is occurring. From a big picture perspective, there are three major reasons one can point to.

Three Key Reasons for Rising Demand for Security Pros
The first is an increasingly complex and demanding regulatory landscape that companies must comply with. This includes well-established requirements such as SOx, PCI-DSS, GLBA, HIPAA and FISMA, as well as new and evolving standards companies will be expected to comply with in the future.

The second, which ties back to number one, relates to the increasing demands that organizations put on each other. Your organization may have a great security program but you are only as good as the weakest link, which may be a vendor or service provider. With the increased scrutiny on partners and providers, the bar has been raised for security programs everywhere.

And third is an increased awareness of security risks from the boardroom to the individual consumer. The old journalistic maxim “if it bleeds, it leads” now applies to cyber breaches and security events, which have become mainstream news. While security challenges are nothing new to practitioners, all things cyber have become a hot topic in the media, especially when it impacts individuals and consumers.

Certainly, there are other factors, but these three issues are some of the biggest drivers that have been contributing to the demand for security and IT risk professionals.

What does this mean to the job seeker? I’ll put it this way:  just because everybody wants to dance, it doesn’t mean they know how… or can even snap their fingers to the beat. More simply, just because organizations are interested in building security programs, it does not mean they actually know what they are doing, especially when it comes to talent.

Over the last two years I have had hundreds of conversations with security professionals who are back on the market a year or less after joining a new company. Why? In most cases, the opportunity was not what it was represented to be and they have been put in a situation where they are either unsupported, professionally regressing, or set up to fail.

This is frustrating because while security professionals are often described as paranoid, skeptical or even jaded – mindsets critical to the job – most are idealists at heart. I don’t know many dedicated practitioners who don’t love the work they do or believe they are fighting for a worthy cause. The truth is, we are in a global technological arms race and it takes special people willing to take on these kinds of challenges. As a result, many go into the interview process with an overly optimistic mindset and don’t ask the hard questions.

Asking the Hard Questions
What are the hard questions? They are the ones that every security and IT risk professional needs to ask while interviewing and before accepting a new position. They are the questions that can uncover future obstacles and allow you to make a more informed, objective decision about an opportunity. So for simplicity’s sake, I’ll break them down into some basic categories:   motive, history, leadership, resources and path.

Here are examples of the questions one needs to ask for each category:

Motive – Why is security important to this organization? What’s driving the program? What are the assets that need protection and how vital are they to the company’s success? How much is driven by compliance? Is security seen as a business enabler or a check box? What are the major initiatives in the coming 1-5 years? Why is the position open? How long has it been open? Is it open due to attrition, a particular security event or part of a new initiative?

History – What do you know about the company’s business? How do they stack up against their competitors? What are the security-specific challenges that organizations in their industry face? What has the company’s past position been towards security? Have they experienced any recent breaches or incidents? Do they have an established program? If so, how large and what kind of attrition have they had? Is this their first effort to build a program? Why? (See motive) How has the preceding security organization succeeded or failed?

Leadership – From the executive leadership team down, what can you learn about the culture of the organization? What is the CEO’s or board of directors’ public position on security? Has there been high turnover at the CIO or CISO level? What about the supporting security organization? What can you learn about the current approach to security? What can you learn about the manager your future role will report to? What has his/her career progression been?

Resources – This is critical for any level, but especially leadership roles. What is the annual budget for security? How is this determined? If more resources are needed, what’s the process for attaining them? To what extent does the security organization rely on external service providers? What is the current and projected headcount of the team? How is the team currently structured? What is the attrition level? If high, why? What kind of internal or external recruiting support can you expect? Does the company pay competitive salaries? Do you have a dedicated HR or recruiting partner? What are your impressions of the interview experience? Is it positive, competitive, effective?

Path – How is success determined? What are the internal growth opportunities? What is the average tenure of previous employees in your role? Where did your predecessor end up? Does the company offer any support for certifications, training or continued education? Does the company allow employees to attend or present at industry events? How does a role with this company align with or support your long-term career goals? How strong is the regional market for security professionals should you decide to move on?

Understandably, it’s not always possible to ask or get answers to every question, but it’s worth the effort. We’re talking about a serious commitment on your part and since there are more jobs than qualified applicants, you have an advantage. Companies that are unwilling or unresponsive to your questions may not be the best choice. In fact, if they are unwilling or unable to answer these kinds of questions, it’s a red flag and the buyer should beware.

Remember, the goal is to avoid landing in a new position that looked great on surface but turned out to be a mistake. Making a career move is a big investment in time, energy and your future. The more a person understands about a career opportunity before they accept, the better they will feel about their situation. With the significant challenges facing all of us, it is more important than ever to get it right. So don’t be afraid to ask the challenging questions. As the saying goes, “Trust, but verify.”

Jeff Combs, J. Combs Search Advisors, LLC

[ISACA Now Blog]