02 Aug Don’t get pwned: 5 questions for information management security
BY JOSH GATKA
It seems that every few weeks, there is news of a new data breach. Each time this happens, I head over to security researcher Troy Hunt’s page, have i been pwned, to make sure that my email address is not linked to any records that were exposed in recent breaches. I’ve been lucky to avoid any serious trouble (so far). In the rare case where my search has resulted in “pwnage,” I’ve only needed to update my password (just in case), and no personal identifiable information (PII) was believed to be at risk.
I didn’t need to experience identity theft or make precautionary phone calls to my bank in order to learn the lesson that breaches happen every day. In my time as Hyland’s security evangelist, and in my previous role as a software tester, I have researched numerous breach timelines.
In many cases, a product or service people trusted to handle sensitive information adopted a poor security stance – which resulted in the exposure of that information. As I read about breaches, I pay special attention to vulnerabilities, exploits hackers leverage, the impact of the attacks, and what can be done to prevent (or at least contain) damage.
5 questions that need answers
Here are five questions to ask your information management solution vendor to help ensure that your data is secure, and that your customers’ email addresses do not end up on the “pwnage” list.
1. Does your solution protect data at every state? (at rest, in use, in transit)
In order to meet the ever-increasing needs of your business, data will exist in multiple states at any given time. Your document scanning software and import solution will ingest documents and save them to a file server.
If these documents contain confidential financial information, your solution should have the ability to encrypt these files. When I suggest this feature to customers, I’m often met with the response: “We already use full disk encryption.”
While full disk encryption is a great layer in a robust security defense, it only protects you from the threat of hard disk theft. Once the server is powered on, and the disk is decrypted, it is not encrypted again until shutdown. Since most file servers need to be online and available 24/7, those files are at risk. Unless, of course, you are using a separate solution to encrypt files until users with the correct rights need to access them.
This is precisely how OnBase Encrypted Disk Groups function. We offer our customers the ability to encrypt entire files, which are not decrypted until accessed by a user with permissions to access the corresponding OnBase document.
Passwords are also a component of securing data at rest. For example, while Yahoo! was in the process of being sold to Verizon, it was discovered in a breach that Yahoo! had been hashing passwords using the very old, very insecure MD5 hash algorithm. Hackers can crack MD5 password hashes using nothing more than a browser (see for yourself!).
Shortly after this revelation, Verizon received a “discount” of $250,000,000 on Yahoo!
It is imperative that you ask your vendor how they store passwords in their database. For example, the right enterprise information platform will “hash” passwords using the strong and secure PBKDF2 password algorithm.
We live in an era of increasing connectivity. Business processes mandate that documents move from scanner to file server, to application server, to workstation, to tablet, to printer, to mobile phone and beyond. And if not touched by human hands, all the better.
Perhaps so-called “smart devices” will enter business processes in places where they aren’t already. What protections does your vendor have in place to ensure that traffic is encrypted end-to-end, and is thus unusable if intercepted by an attacker?
A robust solution will use transport layer security (TLS) to encrypt communications.
There are also ways to protect data that is in use from unauthorized access. If a user of the information management suite steps away from his or her desk to take a phone call, forgets to lock their workstation, and does not return to their desk until the next day, what assurances do you have that data was not accessed by an unauthorized party?
The right solution will protect data in use by providing administrators with the ability to configure idle timeouts. A few minutes after leaving their desk, our fictional phone call recipient would be automatically logged out and would need to re-authenticate upon returning to work the next morning.
2. Does your solution provide secure defaults, right out of the box?
Providing features for your customers that allow them to secure their data is imperative, but not enabling these features by default puts the customer at risk. What if they never remember to turn the features on? What if they are unaware that the feature exists? What if the configuration of the feature is not intuitive, so administrators give up? Or (worse), believe that they have turned the feature on when they haven’t?
Look for a solution that solves this issue by enabling security features at installation. Wherever possible, we strive to ensure the secure option is the one that is enabled by default. Less work for the administrator, and more peace of mind for end users. What’s not to like?
In the last section, I discussed the use of TLS to secure communications. TLS is one example where the secure choice is the one that is enabled by default. If an administrator wishes to communicate insecurely across devices, he or she will need to opt out of TLS during installation.
The same goes for password policies. I don’t need to tell you the risk posed by allowing a company’s payroll manager to select “qwerty” as her/his password. Ask your vendor if it’s solution uses a medium-security password policy by default. User passwords should require a minimum length of eight characters, with a maximum of two repeated consecutive characters.
Additionally, the solution should lock users out after five failed login attempts, and accounts will be automatically locked out after being idle for 180 days. A stricter, high security password policy should also be available for administrators to select as well.
3. Does your solution use granular, role-based access controls?
When you study breaches from the past few years, a pattern emerges:
- The attacker sends convincing, realistic-looking phishing emails to a huge swath of an organization
- Once an unsuspecting victim falls for the phishing email, the attacker installs malware that allows access to that victim’s machine
- The attacker then seeks to “pivot” by infiltrating the network and attempting to gain access to an administrator’s account
- The attacker then leverages the administrator’s account to steal or destroy data, take over machines, and impersonate users
One way to combat an attacker who is using this strategy is to carefully configure permissions for each end user. An administrator should ensure that you are limiting user permissions to the bare minimum that they need in order to do their job. This is known as the “Principle of Least Privilege.” When good access controls are in place, an attacker will encounter much more difficulty.
Think about it, if you are an attacker who is trying to hack into “Organization X,” which account’s credentials are more valuable to you:
- The HR Recruiter: Performs interviews, reviews resumes and attachments, decides whether to move a candidate forward to a second interview or not
- The HR Generalist: Job responsibilities vary, so this account has access to all HR documents, privileges and processes
The second option grants you the most access and privileges. If an attacker were to impersonate the HR generalist in this scenario, he or she would most likely have an easier time pivoting around Organization X.
It is important to limit permissions to the bare minimum needed to perform one’s job duties. This way, if an attacker steals credentials and impersonates a user, they are only able to do what that user could do. It is equally important to select an information management platform that supports the ability to configure account permissions according to this principle.
4. Is your solution tested for common vulnerabilities, such as those listed in the OWASP Top Ten?
Every four years, the Open Web Application Security Project, or OWASP, aggregates data and creates a list of the most critical web application security risks. This list is known as the “OWASP Top Ten.”
Since you can utilize lists like the OWASP Top Ten to drive testing, they should be on your vendor’s radar. The vulnerabilities on this list, if not actively hunted for, can cause real headaches.
At Hyland, we ensure that internal development and quality assurance staff are well versed in common vulnerabilities and exploits, including the ones highlighted in the OWASP Top Ten List. By utilizing secure development practices, automated security scanning, and manual penetration testing, we continually test and secure our solutions against a wide range of attack vectors.
5. Is security taken into consideration at every phase of the product life cycle?
Asking your vendor to describe the role of security at each phase in their development lifecycle can paint a picture of what measures they have in place to ensure they fix security bugs before they ship any software to customers. Prevention is always less costly than reaction, and preventative measures should be a part of your vendor’s development lifecycle at every phase.
When an information management vendor commits to adopting a preventative stance, and requires that security tasks are completed at each phase in the development lifecycle, they are making a statement that they care about defending your data.
Here at Hyland, we chose to implement a custom variation of Microsoft’s Security Development Lifecycle beginning in 2014. At every stage, starting with training and ending with a response phase, our application security team works to ensure our solutions are hardened against attacks. All development and quality assurance employees are trained in how to prevent and detect the types of software vulnerabilities that the bad guys will be looking for.
Going further, we provide our Research and Development staff with the same tools that hackers possess in their arsenal, and then we teach Hylanders how to use those tools. We encourage our staff to throw everything that they have at our software, so that we fix the bugs before the bad guys have a chance to leverage them maliciously.
A “100% secure” solution is a myth. If a vendor tells you otherwise, it means that they are not taking security seriously. With that said, it is important to keep in mind that, according to the 2014 Ponemon cybersecurity study, the average attacker gives up after 90 hours of work.
With enough hard work and diligence, it may be possible to hold out for 90 hours and beyond. You should ask your vendor how confident they are that their solution can stand up to 90 hours’ worth of attacks. Always assume that the bad guys will find those common vulnerabilities, because they may have already done so. Your best bet is to find them yourself first, and fix them!