Interview With Vlad Styran on Safety Detectives

Safety Detectives has recorded an interview with Vlad Styran, VP & Co-founder of Berezha Security: you can read its full transcript on their website.

Safety Detectives is a security product testing lab focused on building a solid knowledge base of antivirus solutions and other personal security tools, such as VPN services and password managers. And they run a blog where they post interviews with cybersecurity experts from around the world.

In the interview with Vlad Styran, Aviva Zacks, Cybersecurity Expert and Writer at Safety Detectives, has covered a bit of Berezha Security‘s history, our approach to professional training, latest advancements in the cyber threats landscape, and, of course, how the 2020 pandemic changes the security industry.

Do we have to put the pentest report on the CEO’s desktop?

Do you pentest against PCI DSS? Do you test for OWASP Top 10? Are Berezha Security reports ISO27001 compliant? These are just a few stunning questions we often hear from our future customers. Although they often sound naive, we have to elaborate on these questions. Otherwise, if our clients know as much as we do, why would they need us? So, in this post, we share some of the frequent customer questions from our presale experience. How many of them are also on your list?

“What methodologies and best practices will you use during the penetration test?”

We touched on this topic in our recent post about different security services. In short — a penetration test copies the attacker’s behavior and shows the customer how the real attacks happen. The pentest demonstrates the vulnerabilities exposed to malicious hackers and what tools they will use to exploit them. With this knowledge, the customer can fix the vulnerabilities before the attacks happen.

Asking about the penetration testing best practices is similar to asking about best practices in hacking attacks. There is plenty of hacker tricks an attacker could use, and the more experienced they are — the thicker it will get. Unfortunately, there is no best practice approach to staying up to date with the hackers as the game is changing too fast. Luckily, we manage to keep our bag of tricks in line with its pace.

“Can you guarantee that the penetration test will do no harm?”

It is quite hard to try to break into something and not break something along the way. Of course, the pentest goal is to improve security and not to ruin the operations. And the rule of thumb for vulnerability demo is Proof of Concept and not real business impact. However, the work’s nature does not guarantee anything because we cannot be sure how fragile the client’s systems are.

To entirely avoid a production impact, we always advise pentesting a copy of the production environment. There are limitations in this approach, as some differences between the production, stage, and test environments are inevitable. However, it is always worth having such segregated environments for other reasons.

And, of course, we have professional liability insurance just in case our error causes any losses. Which never happened to date.

“Show me the sensitive data as proof.”

Imagine a vulnerability is a door that had to be locked, but we found a way to get behind it. The best proof that we got in is showing you something visible only from behind the door. Secret or not, what we show you must convince you to change the lock. Even if, at the time, there was nothing valuable inside. So why would you want a screenshot of the CEO’s email inbox from us? Wouldn’t a screenshot of our successful logon to his laptop be enough? 

By going easy, we minimize the negative impact. We know people love WOW effects, and we collect as much evidence as we need for it in front of a security-conscious audience. However, let us send you an excellent pentest report instead of leaving a bunch of files on your disk. That is what malicious hackers do, and instead of advice on how to fix your issues, you usually find a Bitcoin address there.

We at Berezha Security do have some more questions like this, and maybe this post is just the beginning of a series. Stay tuned and take care.

Zoom enables end-to-end encryption. Will it resolve users’ concerns?

Every crisis is an opportunity in disguise. What companies benefited the most since the outbreak of COVID-19? Most probably, Zoom is on the shortlist. Indeed in the times of the new remote normal, communication becomes a critical part of your life. The number of daily Zoom meeting participants surged from 10 million in December 2019 to 300 million in April 2020. With popularity came attention to the security of the platform. No wonder that with this attention came news of security flaws found in the product. Probably, having end-to-end encryption (E2EE) implemented platform-wide would allow avoiding some of the issues. Let’s take a closer look at this.

End-to-end encryption (E2EE) is a secure communication method that prevents third-parties from accessing data transferred between legitimate users or devices. It is based on public-key cryptography, where the end-users exchange public encryption keys while keeping the private decryption keys secret. It allows for asynchronous encryption systems, where users can safely exchange information without the burden of pre-shared symmetric keys. The data stays encrypted all the way from one user to another and back. So, assuming that a robust cryptographic algorithm is in use and private keys remain secret, data interception becomes virtually useless.

So, coming back to Zoom – ever since they got in the security researchers spotlight, the market was closely watching their progress in implementing the E2EE. It was a crucial point in Zoom’s list as they previously used the server-key based encryption – arguably, the least privacy-focused approach possible. As always, the benefit comes at a price: E2EE demands a delay before a secure connection is established, especially in a multiuser session. Nevertheless, it looks like the Zoom security drama is approaching its end: in mid-October, Zoom announced the plans to roll out the E2EE capabilities. It allows Zoom users to generate individual keys to encrypt voice or video calls between them and other conference participants. Zoom claims this functionality will be available for both paid and free accounts. The Zoom application’s green shield icon will contain a lock if the E2EE is active.

We at Berezha Security encourage using end-to-end encryption to protect your data from interception. Encryption is the most effective protection method for your information assets. We advise leveraging it in different areas, such as digitally signing your emails, using a password manager to keep your passwords safe, fully encrypting your hard drive or at least all sensitive files and directories, and, of course, using the E2EE-capable messengers for your communication.

Simple but timely actions may save you from significant risks. Stay safe and take care.

Difference between application security, security audits, and penetration tests

In cybersecurity, several terms are closely related to each other, such as application security, security audit, security assessment, and penetration test. They are often misunderstood even by cybersecurity professionals. We must speak the same language as our customers and colleagues, so we decided to elaborate on them. Hopefully, you will be able to distinguish them when done reading this post.

Application Security

Intuitively, you could guess that Application Security is the broadest term. Indeed, despite the attempts to narrow it down to specific areas, application security covers a great deal of knowledge. The OWASP Software Assurance Maturity Model (SAMM) provides a well-structured map of application security practices. In that model, Penetration Testing belongs to the section on Security Testing, while audits and assessments fall between Security Testing and Compliance Management. All these are essential practices within the Application Security domain but are far from comprising even half of it.

Now to illustrate the difference between an audit and a penetration test, let us look at the following picture.

Security Audit

As you can see, the audit is a practice that covers the least scope and consumes the most information available on the audit subject. The audit scope is always precisely defined, usually by a standard or policy. The audit outcome compares the organization’s controls and practices for a specific period versus a standard or another set of requirements. And as a result of this comparison, an auditor issues either compliance confirmation or a report full of non-conformities.

Security Assessment

Similarly, a security assessment uses a framework as a benchmark for measurement. However, it usually is less focused on compliance and more oriented toward business risk mitigation. Assessments focus on a point in time instead of a whole period: now instead of during the last six months. An assessment report typically contains not only the findings but also remediation guidance.

Penetration Test

Penetration Test is a controlled simulation of a realistic attack. This exercise aims at measuring the target’s resilience to a real-life cyber threat. Although there are methodologies that describe the tactics, tools, and procedures available to attackers, in reality, they cannot be applied altogether in a single project. Like a real attacker who will use the shortest path to get you, a pentester will apply the most efficient techniques to penetrate your defenses. Unlike an attacker, a pentester will present you with a comprehensive report on identified flaws and how to fix them.

Conclusion

None of the above practices make an organization or an application completely secure. An audit provides assurance that it is compliant with a standard, whilst security assessment and penetration test demonstrate how your business can be harmed and how to make it less likely. To reasonably expect that you are protected from cyber threats, you should apply a combination of practices: some to secure your organization and infrastructure, others to protect your software and customers. However, it is virtually impossible to have any hard proof that the security objective is achieved. If someone tries to convince you that something is secure because it passed an audit or had a penetration test, you should rather treat it as a misunderstanding of these concepts, or a manipulative statement.

Where does Berezha Security stand related to the discussed practices? For sure, Application Security is our main domain of focus. More than 80% of our projects are directly related to software security. We do provide penetration testing and security assessment services, but we do not conduct audits. We also do training and consulting and help implement application security practices.

I hope that this post will help you better understand what security services your organization needs the most. And we are always here to help. Stay safe and take care.

GitHub makes code scanning generally available

GitHub, one of the leading source code hosting services, announces the launch of a static code analysis add-on. Will this become the “silver bullet” for creating vulnerability-free software? Let’s take a look.

About a year ago, GitHub acquired Semmle, whose CodeQL allowed it to treat source code similarly to a database and perform queries within repositories. GitHub leveraged this technology to create a built-in vulnerability scanner.  It was beta-tested by a few focus groups, and now it is becoming publicly available.

The maintainers of public repositories can enjoy its basic functionality for free. It includes security advisories, dependency management and alerts, secrets scanning, security policies enforcement, and authentication practices tests. It also adds security-related checks into the code review flow.

Some of the interesting facts claimed by GitHub about the new functionality are:

  • Twelve thousand repositories were scanned, and more than 20 thousand security issues were found to date
  • Discovered vulnerabilities included Remote Code Execution (RCE), SQL Injection (SQLi), and Cross-Site Scripting (XSS)
  • 72% of those were fixed within 30 days after being found

So, as you can see – the statistics focus on how many vulnerabilities were found and fixed. However, there is no mention of how many suggested vulnerabilities were not (false-positives) and how many of the present vulnerabilities were missed (false-negatives). Both are inevitable companions of static code analysis, which allows examining particular parts of code, but cannot interpret the overall application data flow, business logic, threat vectors, and architecture design weaknesses.

One could compare the source code analysis to examining the bricks for solidity, hoping for the building made out of those bricks to be durable. However, testing each brick is not sufficient for that purpose. Researchers comparing static code analysis results to combined application security reviews conclude that its efficiency (taking into account both false-positives and false-negatives) is between 30% and 60% depending on the programming language and software complexity.

So, while we at Berezha Security encourage everyone to use the new GitHub source code analyzer, we would like to highlight that automated code scanning cannot ensure 100% secure software. It is a good hygienic practice that elevates the security baseline; however, it must be combined with other application security practices, training, penetration tests, and advanced manual security review of highly critical code for the best results.

Stay safe and take care.

How to Hack Customer’s Bureaucracy

Everyone loves getting new customers and projects. However, not everyone knows at what cost we acquire them. And I’m not talking about sales effort right now. I’m talking about the bureaucracy, which is an inevitable companion of a new deal. I want to share some of the issues we often have during the contract closure and advise on dealing with them.

The Deal

The first document you will likely have to sign with a potential customer is a Non-Disclosure Agreement (NDA). Although this document, by its nature, is pretty straightforward and rather hygienic, still, the lawyers can overcomplicate it. Usually, potential customers ask for our NDA template. Funny enough, they never agree to sign it without a round of reviews, which generally don’t add any value.

So Hack#1. The first piece of advice would be not to waste time and ask for your counterpart’s template. This, for sure, will add some load on yourself to review the 3rd party terms. However, it most likely will speed things up. A separate sub-issue with the NDA is that some companies, especially in Ukraine, tend to incorporate monetary responsibility into the NDA. What can you do if you see, say, a penalty of 100K USD in the NDA, knowing that your potential contract worth is 10K USD maximum? 

Hack #2. Well, you can try converting the exact responsibility to a cap (“up to 100K” instead of “100K”), still referring to the “proven damages caused.” This will please the counterpart’s lawyer’s eye but might not expose you to this amount (“proven damage,” remember?). 

Hack #3. Still, it is a good idea to have the professional insurance up to date and its coverage aligned to the penalty caps.

The Contract

Now you are at the contract stage. Will it be challenging? Well, it depends on who you deal with. Our experience shows that foreign clients usually accept our contract template. 

Hack #4. So, the advice is to have a good template aligned with generally accepted best practices. You will still have clients, especially from the post-soviet countries, willing to be very creative with contract wordings. 

Hack #5. Our approach is the following:  we tend to tolerate whatever doesn’t expose us to a higher risk. The only thing we push away gently but firmly:  the business terms (price, payment terms, etc.). 

Hack #6. A separate story is about having a stamp on the contract, which is the archaic practice in the post-soviet countries. Even though in Ukraine it is no longer required, many lawyers and accountants still insist on it. The general advice would be to have the proper justification that the stamp is not required (e.g., the #1982 law in Ukraine) at hand to convince them.

Hack #7. Otherwise:  accept it and have a logistics solution on how to deliver the signed paper contract back and forth.

The Permission

In case you are in the offensive security industry, a small but essential document for you to have is the Engagement Letter (EL). Make sure you don’t do any risky activities without it adequately worded and signed by the client. Your actions will likely have many attributes of activity that would otherwise be deemed illegal, and your only proof of its good intent is the EL. Also, make sure the EL is signed by the party who is eligible to authorize your actions, i.e., the entity owning the asset you are testing.

Hack #8. If there are any issues with EL signing, be firm that it is legally required, and you will not do any work without it because you don’t want any legal consequences. Your willingness to do the job legally is usually convincing enough for the EL to be properly signed by the client’s organization’s highest authority.

The Payment

The work is done – where is my money? Last but not least is to get your payment. I think you are not counting on enforcing the payment legally, right? So how to ensure the customer pays you?

Hack #9. Whenever possible, of course, split the fee and agree on some advance payment, hopefully covering your costs. This may not be possible with some bigger customers since they force all vendors to follow their business terms. You can try using the argument that the pre-payment is needed together with the EL to prove the client’s authorization of your actions that could otherwise be deemed illegal. Sometimes this helps. On the other side, bigger customers usually have better payment discipline, unlike the smaller ones. How to help them pay you?

Hack #10. In case your corporate structure allows it, be flexible in channels of receiving the payment. You may not believe it, but some customers still ask if they can issue a cheque.

Hack #11. And in any case please be kind but very consistent in your reminders. 

Hack #12. Sometimes you can escalate it if there is no payment after a few reminders. Just decide who can be the “bad cop” on your side of the negotiations. And involve this person only when the situation needs to look like an escalation. Same on the client-side ( if you have anyone from a VP / CEO level):  leave this person as a last resort in the escalation. If the reason for the delay is pure negligence, usually, the feel of escalation improves people’s diligence.

The Closure

And of course, I outlined only the key elements of potential bureaucracy, omitting all kinds of RFIs, RFPs, tenders, partner certifications, etc. In the end, please remember: whichever bureaucracy monster you face, treat it just as a cost of doing business. Please don’t take it personally. And justify it precisely as a cost – whenever the return on investment is worth it, go for it. Otherwise, look for something else.

I wish you have clients with reasonable requirements and smart lawyers. 

Stay patient, kind and firm, and take care 🙂

Заява з приводу інциденту у компанії SoftServe

Останнім часом ми отримали ряд запитань про кіберінцидент у компанії SoftServe. Дякуємо всім за увагу та турботу. Ми не будемо коментувати факт компрометації інфраструктури SoftServe, адже це прерогатива керівництва цієї компанії. Натомість хочемо надати факти, які стосуються компанії Berezha Security у цьому контексті.

Компанія Berezha Security навесні 2019 року надала компанії SoftServe послуги з тестування на проникнення. В результаті тестування компанія SoftServe отримала відповідний звіт. Коментувати вміст звіту ми не можемо, адже він складає конфіденційну інформацію. Проте, оцінку якості проведених робіт (5/5) та відгук про спожиті послуги ви можете прочитати на нашому вебсайті та на Clutch.co: https://clutch.co/profile/berezha-security#review-929954. Хочемо підкреслити, що результатом робіт був саме звіт, а не сертифікат чи інший підтверджувальний документ. З будь-якими питаннями щодо вмісту цього звіту ми радимо звернутися до компанії SoftServe, чиєю власністю він є.

Ми з сумом спостерігаємо за інформаційною атакою проти компанії SoftServe, яка базується здебільшого на неперевірених та викривлених даних. Закликаємо користуватися лише підтвердженими фактами та тверезо оцінювати спроби маніпуляції громадською думкою.

Сподіваємось, кожен зробить правильні висновки з цієї ситуації, адже потенційною жертвою зловмисників може стати будь-яка компанія. У світі кібербезпеки немає непробивних стін. Ми перевіряли.

Бережіться.

Threat Modeling Playbook released by Toreon

Toreon, a security consulting company, announced a release of a Threat modeling playbook. This is open-source guidance on how to implement a threat modeling on a corporate level and embed it in the software development process. It starts from getting the stakeholders buy-in, further to the training of people, improvement of processes, and finally covering tools to be used. This work is a result of combining the threat modeling vision and strategy with OWASP best practices like OWASP SAMM and the AppSec champion playbook.

We encourage you to examine the playbook on GitHub and/or view the introductory webinar on YouTube.

In Berezha Security we understand the importance of Threat Modeling practices. You can take a look at one of the presentations Vlad Styran, our co-founder and VP, has delivered on this topic. The Threat Modeling topic is also a part of our Application Security Training for developers, which may be a good support in your adventure in the threat modeling implementation journey.

Serhii Korolenko participated in an EdCamp event

Serhii Korolenko, a Senior Application Security Consultant at Berezha Security, participated recently as a speaker in an EdCamp event.

The general concept of EdCamp is to create a platform for teachers and other education experts to discuss hot innovative topics, share knowledge, and co-educate each other. The movement was born in 2010 in the US and currently involves 44 countries. In Ukraine, it was started in 2015 by a group of volunteers and is now widely supported and held under the Ministry of Education and Science of Ukraine patronage. In 2020, more than 40 events are planned in different regions of Ukraine and covering various topics.

A security-related EdCamp event was organized on the 12th of September by the Putrivka branch and was held online. External security experts were invited to increase the educational community awareness on the topic. Serhii Korolenko gave an awareness presentation on personal cybersecurity – “How not to become a cyber-victim.” The speech was very warmly welcomed and received highly positive feedback.

“Thank you, very interesting and useful. Last week a personal page of my colleague was broken, so this topic is very timely for me”.

“Thanks, very informative.” – here are some of the testimonials from the audience.

Unfortunately, the level of cyber awareness in education is still insufficient. Berezha Security appreciates the effort of EdCamp to improve it among teachers and is ready to support such ventures in the future.

You can watch the recording of Serhii’s presentation below, it’s in Ukrainian language:

Berezha Security is looking for a Junior Application Security Analyst

Here we grow! Berezha Security is glad to announce that we are looking for a new junior team member. This time we are looking for a motivated junior application security specialist, AKA penetration tester. If you are interested in cybersecurity, have a general technical background, are not afraid to face challenges, and learn really fast, then it’s you who we are looking for. You’ll be able to leverage Berezha Security top experts to grow and become an active contributor to the industry.

We are hiring

Although there are no strict requirements for this junior position, we expect you to know the following.

  1. How computers work. An understanding of computer architecture and software engineering.
  2. How networks work. You should know how computers are interconnected and interacting with each other.
  3. How protocols work. We expect you to be able to “read” HTTP or SMTP from day one.

We will help convert your commitment and potential into experience and expertise. Please email us with your CV attached to [email protected].