Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
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.
“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.
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?
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.
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.”
Gliimpse described itself as “healthcare’s platform for patient data. By unlocking patient data silos, we aggregate fragmented data into a patient-owned, longitudinal health profile. Gliimpse is your personal health history, in the palm of your hands.”
Why is this announcement relevant? I think this move could shake up the way we view and manage healthcare data in the long term, and in the short term, influence active conversations being had around patient data, not just in the U.S., but in the U.K. and around the world.
The one goal everyone agreed upon during the conversation at our roundtable was the need for transparency, and the need for patients to know how their data is shared, and why. Gliimpse did a very good job of communicating the benefit to the user in handing over sensitive medical data to the company, “Gliimpse began with a simple idea – everyone should be able to manage their health records, and share them securely with those they trust.”
What is less clear is who (if any entity) will be able to access this type of data in the future, beyond the patient and their healthcare providers. Fortune wrote that “it’s unclear at this point what Apple might have planned for Gliimpse, and that it might soon merge Gliimpse into one of its divisions to work on its healthcare efforts at some point in the future.”
I expect whatever happens, if Apple does roll out a service similar to Gliimpse’s proposition, that there will be a lengthy privacy statement that will provide detail on how the data will be used, and the consumer will need to sign that before using the service.,I imagine that many people will sign up, given the benefits the technology could bring them.
The proposition is certainly enticing. Earlier this year Gliimpse tweeted figures from a HealthMine survey, which revealed that 53 percent of consumers can’t access their electronic health data. The data also showed that 74 percent of consumers say easy electronic access to health data would improve their knowledge of their health and improve communication with their physicians.
The company’s website (which is no longer available, but the text is quoted here) stated “We all leave a bread-crumb trail of our medical ‘stuff’ – our health data and records that we can’t take with us when we leave a doctor’s office or clinic. Providers can’t easily share our records because they’re under HIPAA, the federal regulations regulating how they share patient data. A lack of interoperability makes sharing data nearly impossible. There are no common formats across a myriad of siloed clinical systems.”
“Thankfully, patients and individuals — like you and me — will help solve these two problems U.S. healthcare faces: data-access and data-sharing. How? There are no HIPAA violations when data flows from our health portals to patients. When patients control the data, the problems disappear.” the company states.
The concept of the patients controlling their own data is certainly an interesting one. This would not only circumvent the laws that govern the use of medical records by institutions in the U.S., but could potentially apply to other territories, such as the U.K.
I’m sure we’ve all shared the frustration of seeing our over-worked doctor flick through our paper medical records in a hurry to find our latest test results, or the inability for one hospital to share our data with another. It’s easy to see the benefit of having all personal medical records available at the touch of the button, but only if the system is highly secure and private.
It will be interesting to monitor the uptake of Gliimpse (or whatever the finalised Apple product is called) with U.S. consumers, and how the privacy and security concerns that will undoubtedly accompany the adoption, are addressed. There are many unanswered questions. For example, how will conflicting data be handled? What if a Gliimpse record and an official record differ? How can integrity across records be achieved? With the rise of consumer health apps and devices, will these be integrated as well?
I look forward to seeing the conversation develop.
