Posted by John Verry on Mon, Jul 12, 2010 @ 02:47 PM
Have noted a gradual and interesting change over the last few years. Our security assessment “read-out” meetings where we discuss our findings in detail with the client have gradually become more strategic in nature. We still spend quite a bit of time talking about the more tactical elements of risk mitigation (e.g., what configuration changes need to be made, what patches need to be deployed, what coding changes need to happen) however, we are now spending more time discussing the root cause of the issues and what upstream changes are necessary to reduce the likelihood that the identified problems re-appear.
Even more interesting to me is that we are having conversations even further up the tactical/strategic continuum at initial meetings with our clients. The momentum around ISO-27001 is remarkable. There is a much smaller, but still notable buzz around OWASP as well. Clearly, information insecurity is evolving.
Personally, I’m excited by the change. To me it represents a very significant inflection point – one where we stop looking for technical “silver bullets” to our pain points and we begin apply a more structured methodical system to being secure and proving we are compliant. Leveraging the most open and trusted standards possible – especially those that are well vetted and widely recognized is common sense.
There are many implications to this shift up the continuum, I’m optimistic that the most notable will be that the process will become simpler resulting in a significant improvement in security postures.
Posted by John Verry on Tue, Jan 12, 2010 @ 04:49 PM
With apologies to Mel Brooks ...
As a firm that performs security assessments we are pretty familiar with dealing with sensitive data and go out of our way to handle our client's sensitive data appropriately. We recently finished an engagement where we identified flaws in an extranet business application that exposed sensitive Personally Identifiable Information. We encrypted the report and sent a one-time HTTPS link to the document and left the password for the doc on the client's voice mail.
An hour later the client's Director of Information Security forwarded a non-encrypted email to his internal team, the (outsourced) application development team, me, and the Application Server vendor's tech support -- detailing our exploit.
When I "politely" mentioned to him that forwarding the information in an un-encrypted email to a broad audience had put them at risk and violated their policies (which we had signed at the project outset), he fliply replied, "It's good to be the king."
We had lunch together today and he almost immediately revisited the subject and acknowledged it as a mistake that he had reviewed with the impacted members of his team and vendors.
I was relieved -- as the single greatest predictor of an organization's security posture is the "tone at the top".
Posted by John Verry on Thu, Sep 24, 2009 @ 11:03 AM
... tip of the cap to the late 90's FOX show "When Animals Attack!"
I found the recent Verizon Business
study of more than 500 data breaches during the past four years a very interesting read.
(Kudos to Verizon for their efforts on our behalf.)
Remarkably, 32% of data breaches involved partners' networks being used by an external attacker. To be clear, the largest single source of risk in these organizations was a business partner.
I was (and still am) very surprised by this number. For years, we have stressed the risks associated with system interfaces to third parties and the often ill conceived/executed access connections/channels.
However, to this point I had no reason to believe that it represented that high a percentage of the risk. Having a number of this nature makes it much easier to communicate the information security challenges relating to business partner connections.
So, the next time you look at that partner provided and managed firewall that "secures" the connection between you and a partner, ask yourself if you know enough to know that the risk associated with it is fully understood and well controlled.
Posted by John Verry on Thu, Jul 02, 2009 @ 09:23 AM
In a case of the fox guarding the hen house -- "GhostExodus" a former hospital security guard and a renowned hacker was arrested for painting malicious code on the hospital network as part of a planned July 4th massive DDoS attack.
Scary stuff, but not as uncommon as you may imagine. One of our clients was largely "down" for 36 hours after "voices" advised a security guard to plug in and power a spare switch in the data center and randomly plug cables into it. Can you say infinite loop?
Unfortunately, there are no easy answers. Background checks are critical but not fool-proof. Restricting access to "need to know" and monitoring of privileged access is painful, but very valuable. A (different) client of ours just fully segregated the guards onto their own VLAN as they noted that the guards had been "poking around".
So the next time you smile and roam past the security guard and he doesn't even lift his head from the computer screen ... you may want to find out what he is doing.
Posted by John Verry on Wed, Feb 25, 2009 @ 11:21 PM
More than half of all employees who lost or left their jobs last year took confidential company data with them, according to the study released by the Ponemon Institute and Symantec, 59 percent of ex-employees admitted to stealing confidential company information. The most commonly taken data included e-mail lists, employee records, customer information, and non-financial information.
Over the last year, we have not only had direct experience with similar security incidents, we have also seen cases of extortion and sabotage. Several weeks ago, an outgoing marketing executive intentionally ran SQL updates against the customer data warehouse using somebody else’s account with the intent of destroying the data. The attack was successful. A restore from tape was painful, caused data integrity problems, and resulted in the loss of almost a weeks worth of client transaction history. Sadly, the regular use of shared passwords precluded any opportunity to prosecute.
According to the report - 53% of respondents downloaded information onto a CD or DVD, 42% onto a USB drive, and 38% sent attachments to a personal e-mail account. Now the last group of people is just plain stupid. Lest you think the report is wrong — we have done two forensic investigations in the last several months with the goal being to document a leaving employee’s use of the corporate email system to forward proprietary information to their personal emails and/or a competitor.
Where it gets scary is the use of USB and/or CD/DVD. The vast majority of the companies I work with (with the notable exception of hedge funds) have no mechanisms in place to detect or prevent this type of an inside “attack”.
Officials at both Ponemon and Symantec say they expect the trend to continue, if not worsen, as the economy deteriorates and layoffs increase. “If your organization is planning a RIF [reduction in force], you need to understand the attitudes of the people who are being let go,” says Michael Spinney, an analyst at Ponemon Institute. “Once they’ve lost their jobs, they feel like they don’t really have a lot to lose.”
Sooo … if you are looking at layoffs — you better take a long hard look at your controls over sensitive data before you start dropping pink slips.
Posted by John Verry on Wed, Jan 07, 2009 @ 09:43 AM
Yesterday I had one of those calls that continue to remind me that we all need to be diligent and “eat our own dog food”. It also illustrated very clearly the “hidden risk” associated with allowing remote access to privileged information via employee’s home networks. One of our Information Assurance clients, a pretty “security savvy” developer for a SAAS vendor called, and began sheepishly, “I’ve been hacked and need some advice ….”
A system that he uses on his home network for personal, corporate business, and a side consulting business had been hacked. In order to allow secure remote access to the system, whenever he required, he enabled port forwarding of SSH to that system. Unfortunately, the password was “not as strong” as it should have been. Worse, it was for the root account, which he was using as his main account. A dictionary based brute force attack compromised the system.
I felt bad for him as he had to painfully detail his failure to comply with some very basic security fundamentals. The only saving grace was that his exposure was limited by the fact that he had the system email him anytime a user account was modified. Unfortunately, he didn’t read the email for 2 days.
On his initial/cursory review prior to his call he determined:
- Root password was changed shortly after successful root login followed by four additional remote logins — all from different public IP’s.
- One attempted email outbound whose payload looked to be script generated with no meaningful content.
- No shell history for root for any of the connections.
- No file level logging to determine if user had accessed personal financial data, employer related information, or client data for his home business.
- No outbound logging at his firewall to determine if the system had connected outbound.
- Had not yet reviewed logs for 3 other machines on home network to determine the level to which they are enabled and/or if any access was attempted or successful.
His preliminary plan was to:
- Cancel all his credit cards and bank accounts as this information was stored on the compromised system.
- Advise all clients whose data was on that machine that their Information Technology data was potentially exposed.
- Advise his employer that a machine that had some sensitive employer data and is authorized to communicate through the corporate firewall had been compromised.
- Completely rebuild the server with new drives.
- Rethink/retool his security architecture/practices.
- Potentially pay (out of his pocket) for a full forensic investigation of the compromised systems hard drive.
To paraphrase a famous proverb “It’s the cobbler’s children that often go shoeless.”. In this case, it would have been cheaper to put them all in Prada’s.
Got to run … I have a Linux system on my home network with SSH port forwarded (the truth)… need to revalidate the password is strong, it is IP range restricted, and account lockout is enabled! You should likely do the same …
Posted by John Verry on Thu, Dec 18, 2008 @ 05:15 PM
"We need to fire our lead Security Architect - what do we need to do to ensure he can't hack back into our network after we let him go? " So began a recent call with a new client. In today's economy, I fear that this is a call that we will hear more often and that it is a risk that organizations need good guidance/assurance on.
Many control frameworks (e.g., ISO 27002, COBIT) provide generic guidance on this issue; however, despite my best efforts to Google the topic, I have yet to find more "actionable" guidance on this issue. For that reason, we have begun to compile our own list:
Pre-Firing
- Conduct a network/system level vulnerability assessment/penetration test to determine where you might be vulnerable externally. If your risk profile is high, it would be better to augment the VA/PT with a security architecture review to provide a higher level of assurance.
- Understand what systems are external to your organization for which the user may have privileged access: hosted web sites, ISP routers, exposed administrative interfaces on firewalls, DR sites, PBX interfaces. User account reviews and changing of administrative level passwords post-firing are likely necessary. Be aware that system to system communication may leverage these passwords and that some things may "break" if you don't map these dependencies before making the changes.
- Either war dial or perform a telecommunication audit to ensure that you have accounted for all POTS lines. A good security architecture is easily defeated by a back-door modem. Remember, many mainframes and SANs have modem support lines for DR purposes.
- Either war walk or conduct a wireless security audit to ensure that your WLAN is properly authenticating users, is not visible from public locations outside your buildings, is using an appropriately strong encryption scheme, and doesn't contain any "rogue" access points, which again can be leveraged as a back door to defeat even the best security architectures.
- Ensure that all remote access mechanisms - VPN, Citrix, Terminal Services, and Dial-up modems/RAS are secure. Determine if local authentication takes place at any of these points as post-firing you will need to disable the employee's accounts, do a review/clean-up of all accounts, and force a password change.
- Ensure that your physical security measures are sufficient to protect against unauthorized malicious entry. Try tailgating, validate that security guards check badges, and observe whether delivery personnel are granted access to areas where they should not be. It is common that we can compromise physical security with very simple social engineering tactics like these.
- Validate that you have backups of critical files/applications/configuration so that systems can be restored if necessary.
- Search Social Networks (LinkedIn, Facebook, MySpace, etc.) for your company's name. Although not a direct threat to your data's confidentiality, integrity or availability, the former employee might have noted his employment there. This is a good thing to do regardless if there are any pending layoffs or firings.
Firing
- De-provision access to all systems possible just prior to notifying the individual.
- Provide a severance package that spaces payment over several months and cites that the severance is based on their cooperation and good behavior. This is generally a very effective deterrent.
- Ensure that all assets: phones, PDAs, laptops, credit cards, keys, access cards, and tokens are retrieved and tracked.
- Do not immediately "re-issue" the laptop. Preferably, store it in a secure manner or make a forensic copy of the hard-drive if any suspicious, inappropriate, or criminal activity was suspected. Recently, the forensic copy was useful for a client when they were sued by the ex-employee. On review it was determined that the individual had forwarded dozens of confidential company documents to their home email address prior to leaving. The company counter-sued the employee and eventually won the case. Some companies will review the activities over the previous month or so to determine if the user had accessed sensitive data in anticipation of leaving.
- If the user enjoys administrative access to many systems, before their termination, have them continually observed while they work with a highly trusted individual who will acquire and change passwords for every critical system. We have seen too many instances where a network admin has been fired and escorted out of the building and only after the fact was it discovered that there were systems for which he, alone, knew the admin password.
- Notify all personnel immediately that the person is no longer an employee and that any communication with the individual needs to be reported to management.
- Notify all consultants, vendors, and business partners immediately that the person is no longer an employee and that any communication with the individual needs to be reported to management. One of our clients did not take this step and the fired employee had a consultant pull business critical data from a database and send it to his home email address. The ex-employee explained he was working from home and was having "VPN problems" so the consultant (not knowing the person had been fired two days prior) exported the data and sent it him. This was only discovered after the ex-employee sold the data and a poison pill in the data notified the company.
Post Firing
- Continue to de-provision access to all systems possible. Obvious points are Primary Authentication Servers, mail servers, file/print servers. However, there are often many local authentication points - WLAN, servers, business applications, network devices. For all high risk areas consider a user account review clean-up, and force password changes for all accounts, especially any "shared" administrator accounts.
- Force a password change for all employees (it is not uncommon for an admin to know other peoples' passwords.)
- For all critical systems (remote access, key applications, firewalls, etc.) validate that logging is enabled and working properly and monitor the logs for a period of time to detect any rogue access attempts.
- Leverage your IDS and/or outbound firewall rules/logging to detect any Trojans installed by the employee that may communicate outbound.
- Return to the previously identified Social Networks and ensure that there have not been any disparaging or false comments made about you (if you are the ex-employee's boss or a principal of the company) or the company. While this is not a direct threat to your data per se, disparaging and false information could damage you and your company's reputations, causing lost or diminished future business.
 |
Get a copy of this article in a "brief" document form to reference or to share. Click here for download. |