Gregarius » éléments par Ilia Kolochenko

éléments par Ilia Kolochenko

BetaNews.Com

The pros and cons of implementing a bug bounty program

Publié: janvier 11, 2016, 8:26pm CET par Ilia Kolochenko
A recent incident with the Facebook Bug Bounty program has led to many different reactions supporting both Facebook and the security researcher. Regardless of who is right in that whole story, the one fact is clear: the researcher went far beyond what the social media site had initially expected, and got access to the sensitive data the company didn’t really want to share with anybody, including the researchers’ community.

These days bug bounties have become very popular, raising more and more questions about their efficiency and effectiveness. We will try to understand how and if bug bounties can be used to test your corporate web applications. I intentionally omit bug bounties for stand-alone software (e.g. Chrome or various IoT applications) as it’s a different topic.

On the one side, the crowd-sourcing approach to vulnerability testing used in bug bounties makes a lot of sense. As the more security researchers participate in the audit, the more vulnerabilities and weaknesses they will find. Bug bounties’ "pay per result" approach also may look very attractive for many CISOs who are constantly trying to optimize their budgets to cover all the risks and threats in a very hostile and dynamically changing cyber environment.

On the other side, bug bounties have some pitfalls we need to clearly understand:
1. Do Not Expect Researchers to Take Into Consideration Your Risk Strategy When Reporting Bugs
A vulnerability you may be perfectly aware of, and that you do not plan to remediate immediately for an economic reason, compatibility problem or due to an agreement with your supplier, will probably be quickly reported to you by several researchers at the same time claiming the bounty. A refusal will certainly provoke the rage of the community that will not report any more vulnerabilities to you in the best-case scenario. Such behavior is perfectly reasonable with the "pay per result" conditions of complicated work.
1. Few Researchers Will Carefully Read Your Bug Bounty Guidelines and Conditions
Yes, you may specify any conditions and criteria for vulnerability submission, however few researchers will fully read them and even fewer will practically respect them. Again, don’t be surprised with such comportment when you pay unknown people per results.
1. Bug Bounty Requires Very Serious Technical, Human and Thus Financial Resources
Some people tend to think that bug bounty can seriously reduce vulnerability testing costs as you pay only for results. For the majority of cases, this assumption is totally wrong, as a poorly-implemented Bug Bounty will just spoil your relations with the security community and create a bad reputation for your company.

Some researchers will even intentionally proceed to full disclosure in revenge for lack of responsiveness or award refusal. A good example is the recent mess around Oracle CSO Mary Ann Davidson’s blog post, which berated the constantly growing number of garbage submissions, including copy-pasted reports of automated scanners. If you launch a bug bounty make sure you have enough technical and human resources to handle, analyze and properly follow-up the avalanche of submissions that you are likely to receive -- every single submission should be properly answered in a timely manner.
1. You Will Hardly Distinguish Black Hats and Legitimate Researchers in Your Logs
As soon as a bug bounty is announced, many legitimate researchers from all over the world will start probing your systems. Quite often they will go beyond the initially defined perimeter of testing, trying to compromise a secondary system to get access to the target (e.g. to get source codes of your web application stored on SVN server). Unexperienced researchers and newbies will just start automated scanning with all open-source and free software they will find. Such an environment is an El Dorado for Black Hats to hide in the traffic noise, and a nightmare for your SIEM.
1. Unexpected Testing Methodologies and Techniques Will Regularly Appear on Your Horizon
I personally know two companies that received "bug submission reports" from researchers who proudly claimed bounty payment for DoS attacks against the company’s infrastructure. I omit the huge arsenal of free, often buggy and thus dangerous, tools that (unexperienced) researchers will launch all at once against your systems without any caution.

As a response to some of the above-mentioned challenges, several bug bounty management companies recently entered the cybersecurity market, offering a sort of intermediary service between your company’s bug bounty program and the researchers.

They definitely do great work in helping both businesses and the researcher’s community. However, they have also brought some confusion to the market: some security officers try to compare (managed) Bug Bounties with traditional web security instruments and solutions.

Let’s try to figure out the limits of the bug bounties for web applications in comparison to the traditional web security:
- Bug bounty cannot replace continuous monitoring of your web infrastructure: Continuous monitoring designed to constantly detect newly appearing vulnerabilities has become a vital part of almost any information security strategy. However, you cannot really force researchers to respect any sort of SLA -- they test whenever they want and however they want. So, don’t expect a bounty program to replace your 24/7 monitoring system.
- Bug bounty cannot serve as an additional protection layer to your web infrastructure: Similar to classic penetration testing or vulnerability scanning, bug bounty aims to detect vulnerabilities, and not to patch them or prevent their exploitation (virtual patching). Therefore, even a well-managed bounty will not replace your Web Application Firewall.
- Bug bounty is not suitable to test private systems: Will your risk department feel comfortable sending a 2FA token for your production e-baking web portal to Siberia or Bangalore? Many talented security researchers live there and are listed as top security researchers in the Honor Lists of some of the largest US companies. However, even acting via a managed bug bounty program you will never achieve the same level of financial insurance, compliance, liability and personnel clearance as you may expect from a professional penetration testing company.
Some bug bounty management companies can limit your bounty project to researchers with high reputation, specific skills or even location -- however they just shift their business model towards classical penetration testing with unclear profitability, as the more limits you have the more difficult is to find a qualified researchers who will agree to work remotely and get paid by result. In this case, you’d better hire penetration testers yourself: many small companies in developing countries will offer you very attractive prices and guaranteed scope of work.

Testing methodologies shall be proportional to your web infrastructure and its expected usage in production. Therefore, if you are a large company with numerous publicly facing web applications open to anyone and designed for everyone, a bug bounty program can definitely be a great added-value for your existing security arsenal.

Otherwise, you’d be better off concentrating on the main risks to web applications, and spending your security budget on traditional web security solutions and services that are more suitable to your business needs and technical requirements.

Bug bounty is like hitchhiking: a great way to travel when you are on holidays or have plenty on time, but totally unsuitable for the majority of business trips, which require assurance, quality and accuracy.

Ilia Kolochenko, CEO of High-Tech Bridge.

Published under license from ITProPortal.com, a Net Communities Ltd Publication. All rights reserved.

Photo credit: NLshop / Shutterstock
Return of investment for cybersecurity: Can we put a number on it?

Publié: décembre 29, 2015, 9:03pm CET par Ilia Kolochenko
Almost eight years ago, Bruce Schneier wrote a great article about the problems of ROI calculation for cybersecurity spending within organizations. Since then, both annual spending on cybersecurity and the cost of global cybercrime have significantly increased.

Despite that organizations increased their information security budgets by 24 percent in 2016, many security officers still have to justify to their management every extra thousand spent on cybersecurity. Traditionally, Europe is more conservative than US, and many more European security officers are asked to reduce their initial cybersecurity budgets by removing some items or replacing them with less expensive alternatives.

Businesses need to make money in order to pay salaries (including salaries of the cybersecurity team), so their point of view, based mainly on financial numbers, is pretty clear and reasonable. Nevertheless, if you prepare a well-explained justification for your cybersecurity budget using terminology and language understandable by management, your chances of getting the budget approved without modifications will at minimum double.

For example, let’s take a budget required to protect front-end of a midsize e-commerce website. To stay simple, we will not calculate the risks of chained attacks, such as Advanced Persistent Threats that are starting at vulnerable websites these days.

We will base our ROI calculations on direct financial loss prevention: if by spending $10 you can prevent a highly probable annual loss of $100, your management will happily allocate the $10. Often, the problem is to prove that you really need $10 (and not just $7 or $8) and that the risk(s) mitigated with the $10 really cause a highly probable $100 direct loss to the organization.

First, we need to calculate an ALE (Annual Loss Expectancy): an expected (approximate) financial loss caused by particular risks and threats (if not properly mitigated). We will use a simplified ALE formula from the official guide to CISSP-ISSMP:

ALE = (number of incidents per year) x (potential loss per incident)

In our case, the number of incidents per year can be reasonably set to 12, expecting one serious intrusion attempt via web front-end per month. We can obviously make it bigger, but don’t forget that we are preparing the budget for management who will be skeptical if you present them with numbers that look overstated.

Potential financial loss per incident is a bit trickier, as it consists of numerous factors and sub-factors. Cyber threats will now affect Moody’s ratings, however it’s a very subjective impact as it’s almost impossible to predict if a particular data breach will impact the rating. The same difficulty applies for reputational losses, stock options drop, and all other high-profile losses related to a data breach.

Therefore, we shall try to take an average cost per breach in our industry from a reputable source. For example, according to a recent study by Kaspersky Lab, the amount of financial loss suffered by SMEs averaged $38,000. In some cases, management may question such a "big" amount, therefore, we will need to take tangible and unavoidable incident costs and present them one by one to management in order to validate the amount. In the case of e-commerce web front-end, it’s pretty easy to identify at least some them:
- Cost of customer database and other sensitive information theft and exposure
- Cost of e-commerce portal unavailability during forensics and recovery
- Cost of third-party experts allocated to investigate and remediate the breach
- Cost of legal and compliance fines.
Obvious and easily calculable costs are related to PCI DSS compliance. If for example you have PCI merchant level 2, you will be "promoted" to level 1 in case of data breach with all the related costs. Costs related to third-party consultants are also simple to calculate, estimating that they will have to spend at least one week investigating the incident -- you already have at least $10,000.

For example, TalkTalk (due to the size of the business and the scale of hack) has lost about £35 million in total, and in comparison to them $38,000 looks very reasonable. Even a higher cost per incident comes from the 2015 Information Security Breaches Survey published by UK government and PwC, where the average cost of data breach for SMEs is between £75,000 and £310,800 ($112,000 and $466,200 respectively). But let’s come back to our modest $38,000 for our example and use it in our equation:

ALE = (number of incidents per year) X (potential loss per incident)

ALE = 12 X $38,000

ALE = $456,000

This is the amount a company should expect to lose per year if nothing is done to protect its web front-end. Of course, each new incident will aggravate the losses, but here we can omit this point.

The next step is to justify the money you are asking for. The easiest way to do so is to provide your management with the most efficient and effective solutions and products, carefully selected by the price/quality ratio. In order to protect the web front-end (I omit SDLC and all other costs related to secure development, maintenance and compliance) we typically need:
- Web Application Firewall -- despite that a WAF cannot protect from sophisticated attacks, it’s a great protection layer against bots and other malicious "noise", automated attacks and script-kiddies.
- Continuous vulnerability scanning and security monitoring solution -- what is secure today may become vulnerable tonight, and an annual penetration test will not detect it on time. Therefore, continuous security monitoring is extremely important.
- Regular manual or hybrid assessments involving third-party experts -- a good example is a critical RCE in Zen Cart, recently detected by High-Tech Bridge in the latest version of this popular e-commerce platform. The vulnerability is present only in the latest version, and was not detected by any of automated scanners prior to our discovery.
Estimating that a) + b) + c) will be $40,000 per year, we can come back to our equation and calculate ROI. We will take ROI formula from the official guide to CISSP-ISSMP:

ROI = (ALE / cost of countermeasures) X 100 percent

ROI = ($456,000 / $40,000) X 100 percent

ROI = 1140 percent

Even if such a huge ROI may be subjective from a purely technical point of view, it will definitely convince your management better than a long saga about the dangers of blind XSS attacks.

Robert Metcalf, a cybersecurity expert at PwC Switzerland, says: "Cybersecurity is about risk management and loss prevention, not just earnings and so any investment in security needs to demonstrate to the business that it is focused on defending what is of most value to the organization, its 'crown jewels'. How these key assets are then being targeted by threat actors can strongly indicate where you must invest the most and where your business reputation is also at stake".

If you speak with management about money -- speak their language and you will definitely get what you need.

Published under license from ITProPortal.com, a Net Communities Ltd Publication. All rights reserved.

Photo Credit: Joe Wilcox
Advanced Persistent Threats still go unnoticed by website owners

Publié: août 14, 2015, 9:35am CEST par Ilia Kolochenko

The term "Advanced Persistence Threat" fills news pages on a regular basis. According to ISACA APT Awareness Study, 93.6 percent of respondents consider APTs to be a "very serious threat" for their companies.

However, many "APT" attacks, do not really fall under the 'advanced' category in terms of the attackers’ sophistication. A very recent exploit, combined with phishing or newly registered domains are rather "low-cost APTs", for which we should probably introduce the new term "LCAPT" or just "LAPT" to distinguish these from genuine APTs.

Genuine APTs usually involves exclusive zero-day exploits, custom-made malware, complicated techniques of data exfiltration to bypass corporate IDS/DLP, and a preliminary compromise of several trusted third-parties of the victim. These attacks are extremely difficult or even impossible to detect. Cyber-mercenaries behind these attacks are not [only] Chinese army officers or Russian teenagers as many tend to think. They have legal, financial and banking industry experts, psychologists, and even ex-law enforcement officers amongst them. Business knowledge combined with advanced technical skills and the ability to fool law enforcement agencies by knowing their methodologies of work, make APT a very serious and costly problem.

Taking a closer look at the APT lifecycle will help to understand how APTs usually start. The very first step is to select the right approach to appropriate victims in the targeted company. Hackers perform very thorough due-diligence on their victims, carefully selecting those who have a necessary level of access to the data that they are looking for. APTs are different from other less sophisticated attacks by very well prepared attack scenarios that will work in 9 out of 10 cases.

Unfortunately, human psychology cannot be altered solely through security training and awareness; our basic instincts will always dominate our acquired skills. We were recently assisting a medium-size insurance company that decided to outsource cybersecurity management to a third-party provider, cutting the majority of internal security jobs. Security people received a very well prepared [fake] email from the management about their future placement and dismissal compensations. Everyone, including senior security experts who have been in the industry for dozen of years, clicked on the included link.

Once the victims are properly selected and the attack scenario is ready, it’s time to deliver a zero-day exploit to execute arbitrary code on victim’s machine, install a backdoor and start invisible expansion to other machines in the local network. Different to all existing Bug Bounties, zero-day exploits can earn researchers potentially hundreds of thousands of dollars . Usually, zero-days are outsourced to hacking teams specialized in exploit development. The most traded zero-days target vulnerabilities in client-side applications, such as browsers, Adobe Flash and Reader, or MS office.

One of the most important points is how to deliver the exploit and compromise the victim in such a way that both the victim and corporate security solutions won’t notice anything. Sometimes hackers start loud DDoS attacks or simple large-scale phishing attacks with known attack signatures that will flood corporate SIEM with messages and attract all of the attention. Therefore, if you are observing how well you have just blocked a large-scale intrusion to your network, be sure to check that it’s not a smoke screen to hide an APT.

Usually, the exploit is delivered as an attachment to an email or as a link to website. Email attachments are used less and less in APTs, hackers would rather send a legitimate URL which the victim will blindly and unquestionably trust, such as to your corporate website.

These days, companies have a great choice of advanced cybersecurity solutions to prevent, monitor and block network intrusions. According to PricewaterhouseCoopers The Global State of Information Security® Survey 2015, 49 percent of respondents spend money on specialized solutions to prevent and block APTs. However, often once a C-level manager is blocked and prevented from his daily work with a false-positive intrusion alert, all of these solutions are set into silent monitoring mode. Current business needs are much more important for the majority of top-level managers than potential security risks that they may theoretically face in the future.

Web traffic inspection is usually based on the monitoring of anomalies, known attacks and payloads patterns, reputation and history, and many other drive-by-download detection techniques. However, there are almost always a couple of websites and web applications that are whitelisted for business reasons. One of these is usually a corporate website, as people don’t expect their corporate portal to deliver malware and therefore, in order to reduce number of logs and work, just remove it from the monitoring scope. This is a great gift for hackers, as even a tiny stored XSS on your website enables attackers to deliver the exploit, compromise and backdoor the victim, and then go further into your network. All these factors make your corporate website a perfect vector to host the exploit.

Sometimes attackers won’t deliver their payload at the first click, they would rather reconfirm that the victim is using the "right" browser and OS version first, and then deliver the exploit with the second email and link.

We recently saw a more exciting case where no client-side exploits or malware were used at all. The victim company had a centralized access management of their corporate resources via a web system that grouped email, CRM, HRM and other business-critical applications. The company was recently acquired by a bigger competitor, and many employees were scared to lose their jobs. Hackers managed to compromise one of the subdomains of the corporate website that was hosted on a separate server and didn’t contain any sensitive information.

Then they sent emails from the compromised web server asking employees to login into the website using their corporate credentials, and follow a step-by-step questionnaire that was supposed to define whose jobs were likely to be cut. Moreover, the website worked perfectly: employees were asked to answer a dozen credible questions (e.g. work experience, desire to stay, family status, etc), making people believe that it was a perfectly legitimate system. At the end of the questionnaire, every employee received a message that he or she would keep their job. Overflowing with positive emotions, nobody even thought that their password had just been stored in plaintext for further usage by the cybercriminals to access all their corporate data.

A tiny vulnerability in your corporate website or its subdomain may ruin all the efforts you take to protect your company from APTs. Therefore, when planning your annual cybersecurity budget, don’t forget about regular website security audits, otherwise all other spending may suddenly become useless.

Ilia Kolochenko is High-Tech Bridge’s CEO and Chief Architect of web application security service ImmuniWeb.
Practical step-by-step guidance for after your company has been hacked

Publié: juillet 2, 2015, 7:22pm CEST par Ilia Kolochenko

Everybody tends to think that hackers will never ever target them or their company/organization until a breach occurs. I've already written several practical examples explaining why hackers target you and your data.

Here, I will try to concentrate on post-incident actions and provide some brief advice on what to do after you have been hacked.

Step 1: Avoid panic and focus

Many companies aggravate the consequences of a data breach and disrupt legal investigation through enormous internal panic. Keep in mind that you are not the first victim of hacking, nor the last one. Now your role is to focus your and your team’s efforts on minimizing the consequences of the actual data breach. Moreover, the fact that you have identified the breach -- is positive, as many companies do not even know they have been compromised due either to highly sophisticated hackers or the internal technical team’s negligence.

Step 2: Gather your team and assign roles

Once the initial panic has subsided, gather the incident team. Each company structure is unique, but make sure that your technical, legal, public relations, and sales teams are present. Technical teams will obviously be in charge of the technical aspects of the incident handling, the legal team will assure compliance of your investigation with the law, PR needs a clear corporate position for the media, while the sales team needs to be clear about what to say to your customers. It is very important to synchronize all teams, make sure that no team takes an initiative without your approval and without notifying the others.

Step 3: Understand what happened, which data was compromised and how

One of the most important steps is to understand what really happened. Sometimes companies panic on hearing of fake hack announcements organized by unhappy customers or unethical competition. Others deny data breaches until all compromised data appears online and makes headlines. Your technical team should be able to tell you which systems and data were compromised, which vulnerabilities were used by hackers to get in, assure that compromised systems are properly isolated, and ensure that hackers didn’t leave any backdoors or logic bombs.

Step 4: Carefully collect logs and other evidence

Make sure your security guys don’t erase or alter any logs during the investigation process, otherwise a court of law may reject them as evidence later. If you don’t have enough in-house expertise to properly conduct incident forensics -- call an external company to perform the technical aspects of the work. If you know which systems are breached -- disconnect them from the network (including the local one) as hackers may still be here mining your data, installing backdoors, and erasing logs.

Step 5: Analyze and evaluate the origins of the breach

It is very important to understand how hackers got into your network. Depending on the entrance path, you need to take urgent action to prevent them re-using the same vulnerability or similar hacking method. For example, if one of your trusted supplier’s accounts was hacked and used to login into your network -- make sure that all the accounts of this supplier are blocked until they perform their own incident forensics, as their entire network may be compromised and backdoored. Make sure that other systems and networks under your control cannot be compromised in the same way. For example, if hackers exploited a zero-day in one of your applications hosted on dozens of different servers -- make sure that a temporary solution that prevents exploitation of the vulnerability is implemented ASAP, otherwise you will see a domino-effect compromise.

Step 6: Analyze the consequences of the incident and prepare a disclosure plan

Once you know what happened and how happened, it is time to analyze the business, legal, reputational, and financial consequences of the breach. Make sure your legal team participates fully, as legislation on data-breach disclosure is very different from state to state, and from one country to another. In any case it is better to disclose the breach to all concerned parties, as even if you’re not legally obliged to declare the incident --your reputation will suffer much more if someone else (including the hackers) discloses the hack instead of you. Remember, that if you disclose the breach -- you will be able to present information properly and even reinforce your business reputation by demonstrating that you are handling the incident seriously. While if hackers or someone else discloses for you -- don’t count on their mercy in detailing the hack. Obviously, you don’t need to shout on every corner about the data breach: if a limited number of customers were impacted -- just make sure all of them are notified in a proper and timely manner.

Step 7: Disclose the incident to concerned parties and notify law enforcement agencies

Timing of disclosure is very important. Assuming there is no legal obligation to disclose, it’s very important to choose the right timing. If you disclose before you see a full picture of the incident, you may help hackers and scare your customers who will not appreciate the uncertainty. If you disclose after hackers have already re-used all passwords and other customer data to hack them – your business reputation will suffer a lot, you risk losing loyal customers and facing several lawsuits. When disclosing the incident make sure that all your customers, or any third-parties that suffered from the breach, feel that you do care about them, about their data, and that you are doing your best to help them, to punish the criminals, and to prevent such incidents in the future. Once again -- a properly performed incident forensics and handling may reinforce your reputation and brand value, while other businesses fail to act properly after a hack. As soon as you finish the technical part of incident forensics, notify law enforcement agencies. Despite the fact that a well-organized hack by skilled attackers will hardly be solved via technical investigation, your data may be extremely helpful for detectives, who may be looking for a missing piece of puzzle to uncover a hacking team breaching companies in your industry. This is how many hacking teams were stopped, as in one or two breaches they made a couple of tiny mistakes unveiling them.

Step 8: Revise your security policies and strategy

No security policy is perfect, and the data breach confirms the need for your security policy and strategy. Even if your systems were not breached directly, but a third-party’s with privileged access -- now it’s your task and responsibility to prevent such similar hacks in the future. Use the data breach as a lesson to prevent more expensive hacks in the future that may cost you much more.

If you read this article -- you are already on the right way to responsible and proper incident handling!

Photo Credit: lolloj/Shutterstock

Ilia Kolochenko is High-Tech Bridge’s CEO and Chief Architect of web application security service ImmuniWeb.

Gregarius » éléments par Ilia Kolochenko

Canaux

éléments par Ilia Kolochenko

BetaNews.Com

The pros and cons of implementing a bug bounty program

Publié: janvier 11, 2016, 8:26pm CET par Ilia Kolochenko

Return of investment for cybersecurity: Can we put a number on it?

Publié: décembre 29, 2015, 9:03pm CET par Ilia Kolochenko

Advanced Persistent Threats still go unnoticed by website owners

Publié: août 14, 2015, 9:35am CEST par Ilia Kolochenko

Practical step-by-step guidance for after your company has been hacked

Publié: juillet 2, 2015, 7:22pm CEST par Ilia Kolochenko