Berezha Security is 6 years old! What’s next?

Berezha Security turns six years old! Indeed, this year was the weirdest one with its challenges and all the changes happening in the world. However, it was still a good year: we completed over 50 projects and continued to grow.

Our co-founder Vlad Styran recently brought up a few memories of how the company was founded in 2014. It was not a typical business startup; it was rather a lifestyle endeavor. We base Berezha Security on the principles that quality comes over volume, value over cash, long term benefits over short-term yield. It allows us to be a reliable partner, a durable employer, and a consistent community contributor throughout these years. And our client feedbacks prove that in the best way. We plan to keep these principles untouched. However, we do want to give you a heads up on what is coming next.

When we founded the company, the name and the brand were chosen rather opportunistically. Through all these years, we have built an emotional connection to it we hope you did too. Nonetheless, we have decided that we need a little bit of change for future growth and a better reflection of our vision. The new brand name will be very much connected with the current one, but at the same time renewed. We are still working on its details, but we already know – it will be great. Probably it will be the best birthday present for us, so just wait for it 🙂

We are glad to be such a strong team of similar-minded professionals, and we are looking forward to the 7th year of our journey together. Happy Birthday to us!

Remote Work Security Audit – a Need or a Habit?

A year ago, before the COVID-19 pandemic, probably very few people could imagine how the world would change. Working from home, remote business meetings, online events, and digital concerts are only some new normal examples. The things we could not imagine going virtual very much did, to everyone’s surprise. One of the areas that tended to be very onsite and face-to-face was conducting a security audit – remote work security assesment.

Sure thing, that approach to auditing is also being revisited right now. Is remote audit possible without sacrifice on quality? Is onsite audit more a cultural thing or a real need? These are questions that arise; let’s try to look for the answers together.

What is a Security Audit in our meaning?

First of all, let’s recall that audit is a set of procedures to ensure that the audit subject complies with some requirements. For example, financial reports may be required to comply with IFRS. At the same time, the payment card data processing processes should meet the PCI DSS requirements. So, the first thing that matters – is what the requirements are. The more they relate to the audited subject’s physical environment, the more difficult it is to avoid onsite audit procedures.

Another significant factor would be the business’s nature, how physical it is – for example, a manufacturing business versus software development. And not least – the level of knowledge an auditor has about the audited company and the level of established trust. Yes, we know – audit should always follow the zero-trust rule. Although it is right in general, audit standards usually fall back to ‘reasonable assurance,’ which translates to ‘low-trust’ instead of ‘zero-trust.’

Typical Cybersecurity Audit procedures

Let’s go into some details and look at the typical security audit procedures. The critical objects audited would be digital assets (e.g., configurations and code, also known as CIs in ITIL), controls, and evidence of their effectiveness.

For the digital assets, the typical audit procedure would be examination, or in worst fact, observation. During an onsite audit, an auditor would usually have a meeting with someone who has access to the asset. During the meeting, the asset would be presented, and key artifacts (logs, screenshots, config files, etc.) would be provided (sent by email, copied to a thumb drive, etc.) to the auditor for further examination. The audit conclusion would come from the examination results.

So the meeting’s goal is to identify the assets and ensure that the auditor obtained the requested information without any interference. This audit practice can be replaced by a remote meeting and a screen-sharing session without compromising the audit quality. One could argue that it can provide an even better experience to the auditor.

Audit of manual controls may require sampling and physical evidence (whereas the automated controls audit is less demanding). During the onsite audit, the auditor can sometimes do sampling on the fly. I.e., picking the sample during the meeting, and then only sample evidence would be requested for examination. A remote audit would convert it to giving the whole population of cases and sample based on it.

In theory, it should lead to even better audit quality. However, it may be challenging for some physical evidence types to provide the whole population for sampling. Imagine a physical registry of entry to the building. Should the auditee scan and send it for sampling? How can an auditor make sure no pages are torn out from it? So there may be cases where the remote audit quality suffers, or the audit cost noticeably increases.

Of course, any audit of non-digital assets (like physical security) or digital assets connected to physical endpoints (e.g., LAN access from a physical socket) is difficult to replace with purely remote procedures.

Remote and Onsite Cybersecurity Audit Standards

Let’s see how official audit standards will change to incorporate the new normal of pandemic times. We at Berezha Security would see the following approach to onsite procedures beneficial for both the audit quality and the auditor’s safety:

  • In case the auditor can get safely to the place of audit, ensure the environment itself is safe, e.g., no close physical contact with other people, premises are regularly disinfected, etc.
  • In case the auditor can’t get safely to the place, involve 3rd parties that can and instruct them to assist the auditor and ensure the evidence chain of custody
  • In case neither is possible, organize a virtual experience using a secure video-conferencing tool to show the auditor everything they need to see

It’s important to remember that in both remote and onsite audits, the key to good audit quality lies in identifying and understanding what is audited, control over information selection, and data sharing procedures. As an auditor, make sure you decide what to select, make sure you examine what is indeed deployed, and see what you want to see, not what you are shown. Adhering to these basic rules will allow most audit work to be done remotely without compromising quality. Let’s leave the pleasure of face-to-face meetings and small talks for safer times.

Stay healthy, and take care.

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.