{
    "componentChunkName": "component---src-templates-about-blogs-js",
    "path": "/en/blogs/",
    "result": {"data":{"blogpage":{"lang":"en","SEO":{"title":"Balasys blog | Balasys IT Ltd.","isIndexable":true,"description":"Balasys blog","keywords":"Balasys blog","preview":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/balasys_logo_dark_horizontal_600x400_ce49b26647.png"}}},"blogposts":{"nodes":[{"author":"Szilárd Pfeiffer","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/jievani_weerasinghe_NHRM_1u4_GD_A_unsplash_5998edbcc5.jpg"},"content":"**Researchers at **[Kudelski Security](https://kudelskisecurity.com/)** have **[managed to break](https://research.kudelskisecurity.com/2023/03/06/polynonce-a-tale-of-a-novel-ecdsa-attack-and-bitcoin-tears/)** Bitcoin and Ethereum wallets using a novel attack against one of the most popular asymmetric key algorithms of modern cryptography. Although **[Satoshi Nakamoto](https://en.wikipedia.org/wiki/Satoshi_Nakamoto)**’s wallet was not among the 764 wallets they were able to break, it is quite worrying to see that a software issue can make such a modern cryptographic algorithm like ECDSA vulnerable. Analysis of data that comes purely from open sources could reveal a practical weakness of an algorithm that is the fundamental basis of secure internet communication, public key infrastructures, and cryptocurrency transactions.**\n\n\n## Software Issue Behind the Scenes\n\nAs with many other times in the history of attacks against cryptographic algorithms, the cause of a successful attack is not a vulnerability in the algorithm itself, but the fact that poor-quality software used an algorithm with insufficient care. It is crucial to obtain “high-quality” random numbers during the calculation of many cryptographic operations. Such operations store passwords using [salt](https://en.wikipedia.org/wiki/Salt_(cryptography))ed [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function)es, the generation of cryptographic keys used to authenticate web servers on the internet, or an employee before access is given to the company’s private network using a virtual private network (VPN) service. The generation of [digital signature](https://en.wikipedia.org/wiki/Digital_signature)s – which is necessary for the verification of the transactions – also requires a cryptographically strong random value. In the absence of strong random values, there would be a relation between the random and the private part of the signing key. This property could be exploited, and the private key can be acquired by an attacker. In the possession of the private key, any transaction related to the key can be verified, meaning that the balance of the wallet can be transferred.\n\n\n## Not a New Idea, but a New Method\n\nThough the attack itself is novel, the idea behind the attack is not so new. The lack of high-quality random numbers has caused serious vulnerabilities in the past. In 2002, a researcher found an [issue](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2008-0166) in the version of the [OpenSSL](https://www.openssl.org/) distributed with [Debian](https://www.debian.org/) Linux and its derivatives that reduced the entropy of generated random values. The issue caused SSH, VPN, and X.509 keys generated by the affected versions of OpenSSL to become vulnerable. Services still used a key generated by the affected version of the code which meant they remained vulnerable until the regeneration of the key. In 2010, a group called _fail0verflow _compromised an ECDSA key [Sony](https://en.wikipedia.org/wiki/Sony) used to sign software for the [PlayStation 3](https://en.wikipedia.org/wiki/PlayStation_3) game console. The root cause of the attack was almost the same as it is now, namely Sony did not use different random numbers when digitally signing different software. The novelty of the current attack is that it exploits the high-degree relationships among the random values ([nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce)s) used to generate digital signatures. It means if the nonce was not generated by a cryptographically secure random number generator but using a weak [pseudo-random number generator](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) (PRNG), it would allow the attacker to retrieve the private part of the key used to generate the signatures.\n\n\n## Special Kind of Open-source Intelligence\n\nThree prerequisites must be met to successfully retrieve the signer’s private key from signatures. The first one is that the random value used to generate the signature should come from a weak PRNG. The second one is to have a batch of consecutive digital signatures generated by using the same PRNG. The third one is that the signatures can be ordered, meaning that we know which signatures have been generated after which one. It could be assumed that there are implementations that use weak PRNGs as it is not basic knowledge whether random number generators are adequate for cryptographic purposes and some legacy software may follow older guidelines. The question is: where can an attacker find a consecutive and ordered list of signatures? The answer is: in several places. Digital signatures are part of each cryptographic protocol, so they can be collected from open sources. The best examples are [cryptocurrencies](https://en.wikipedia.org/wiki/Cryptocurrency), where the transfers are validated by digital signatures. These digital signatures must be published to allow each party to validate the transactions. Basically, cryptocurrency [blockchain](https://en.wikipedia.org/wiki/Blockchain)s are huge collections of the necessary signatures. For instance, researchers could collect 763 million unique signatures from the Bitcoin blockchain which were generated by 424 million unique public keys. Most of the time a key was used to generate only a few signatures, but millions of keys generated at least four signatures, which is the minimum requirement of the attack.\n\n\n## Someone Got Ahead of the Researchers\n\nResearchers ran their attack for two days and 19 hours with an estimated cost of USD 265, resulting in 762 unique broken wallets, but someone may have gotten ahead of them, as all the wallets had zero balance. The researchers suspect that these wallets have already been hacked in the past. If they had not been hacked, 484 BTC could have been stolen from these wallets, which means almost 12 million USD. However, 484 BTC was worth 31 million USD at Bitcoin’s peak. The question arises, where did the money go? The researchers obtained that the recipients were addressed by the latest transactions of the broken wallets. They identified 466 different recipient addresses, where the top 1 received 75 BTC, and the top 5 received 140 BTC, meaning more than USD 1.5 million, and almost USD 3 million, respectively. They counted 144 BTC in total, which is far from the theoretical 484 BTC, but it still sounds like a profitable business, worth the aforementioned USD 265 cost of the investigation. After the first transaction to the top address in 2018, several transactions were initiated from that address to several recipients for 0.5 or 1 BTC, although the account still had a balance of 63.5 BTC. Researchers also found public conversations about accounts that were swept exploiting repeated nonces. A forum member called _johoe_ [claimed](https://bitcointalk.org/index.php?topic=1431060.0) that he had collected 135 addresses that can be compromised using that technique, and 82 had been compromised already at the time of his post. He also stated that he collected 7 BTC from the broken accounts. He was willing to send the funds back to the owner after proving ownership. The researchers repeated their attack against Ethereum after collecting more than 1.7 billion ECDSA signatures. They managed to break 2 unique wallets processing 22% of their signature collection. They decided to stop the attack, considering that the cost-benefit ratio was too low.\n\n\n## Is This Still a Real Issue Now?\n\nConsidering only the results related to the Bitcoin wallets, I would say this might not be an issue anymore. The exploitable signatures were generated several years ago, perhaps with the same software that had a serious flaw, which may have already been fixed. The signatures were exploitable not because they used a pseudo-random generator during signature generation, but due to repeated nonce values. At the same time, given that digital signatures are used in so many cases, such as during a cryptographic handshake, this may still be a significant issue. Exploiting the vulnerability indeed requires getting consecutive signatures from a potentially affected server, which is not a trivial problem in the case of a busy server, as many other clients connect to a server between our consecutive connections. Even so, if an attacker manages to exploit a server, the server certificate is compromised without any sign on the server. For as much as the [certificate revocation is one of the weakest points of X.509](https://pfeifferszilard.hu/2020/09/09/why-do-certificate-revocation-checking-mechanisms-never-work.html), it is troubling that such a simple flow in an implementation can cause certificate compromise. The case would be even more worrying if there were a similar flow in certificate issuance, as this would compromise a CA, which could result in unpredictable consequences.\n\nPhoto by[ Jievani Weerasinghe](https://unsplash.com/@jievani?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on[ Unsplash](https://unsplash.com/photos/NHRM1u4GD_A?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n","date":"March 16, 2023","id":"Blogposts_36","short_description":"Researchers at Kudelski Security have managed to break Bitcoin and Ethereum wallets using a novel attack against one of the most popular asymmetric key algorithms of modern cryptography, ECDSA.","isEnglish":true,"isHungarian":false,"slug":"bitcoin-account-hijacking-ecdsa-nonce-break","title":"Bitcoin account hijacking using OSINT techniques"},{"author":"Szilárd Pfeiffer","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/christian_lendl_Zytt_G_Su_o2_E_unsplash_76adf1b110.jpg"},"content":"**Quantum computing not only poses a great opportunity, but also a great threat to internet security. According to the promises of quantum computers, certain mathematical problems that form the basis of today’s most popular cryptographic algorithms will be much easier to solve with them than with classical computers. In a recent publication, Chinese researchers claim that there is an existing algorithm that, even with today's quantum computers, makes it possible to break the RSA algorithm, which is the fundamental basis of secure internet communication. At the same time, there are doubts about the reliability of the publication. However, even if these doubts are confirmed, it does not change the fact that the security threat posed by quantum computers remains with us.**\n\nThe basic claim of the [paper](https://arxiv.org/pdf/2212.12372.pdf), published last Christmas by 24 Chinese researchers, is that they have found an algorithm that enables 2,048-bit RSA keys to be broken even with the relatively low-power quantum computers available today. There is nothing really new in the fact that quantum computers pose a general risk to the reliability of cryptographic procedures that guarantee secure internet communications, such as [RSA open-key cryptography](https://en.wikipedia.org/wiki/RSA_(cryptosystem)) or the Diffie-Hellman key exchange algorithm. These procedures are based on mathematical problems that are practically unsolvable with conventional computers, but which can be solved in a few hours with sufficiently powerful quantum computers. Sufficiently large means 20 million [quantum bits](https://en.wikipedia.org/wiki/Qubit) (qubit) in this case. The problem with this figure of 20 million is that <span style=\"text-decoration:underline;\">IBM's quantum computer</span> – the largest quantum computer known today – can only render 433 of these 20 million qubits. It is not an exaggeration to say that the Chinese researchers chose one of the steepest hills to climb. But can they really overcome this challenge?\n\n> [Integer factorization](https://en.wikipedia.org/wiki/Integer_factorization) is the most widely used infeasible mathematical problem to guarantee that the cryptographic algorithms are practically unbreakable. Factorizing a number consisting of only a few digits is trivial (15 = 3 * 5), but the required computational capacity grows exponentially along with the number of digits. For hundreds or even thousands of digits, the computational effort required is so enormous that even using the highest performance supercomputers, the time required to do the calculation would be similar to the lifetime of the universe. According to the [recommendation](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf) of the [National Institute of Standards and Technology](https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology) (NIST), the smallest RSA key size that can be considered secure is 2,048 bits. This means approximately 600 digits, but in many cases larger keys of 3,072 or 4,096 bits are also used. There, the number of digits expressed in the decimal number system already exceeds a thousand, meaning that these keys are practically infeasible with traditional methods. At the same time, in 1994<span style=\"text-decoration:underline;\"> [Peter Shor](https://en.wikipedia.org/wiki/Peter_Shor)</span> already came up with an [algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) that – on a quantum computer only existing in theory at the time – would be able to perform the prime factorization with much greater efficiency than before. This breakthrough would imply that a significant part of our encryption procedures would no longer be resistant to breaking, including, among other things, HTTPS, which ensures the security of browsing, or VPN protocols, one of the foundations of remote work.\n\n## Has Cryptographic Apocalypse Now arrived?\n\nThe Chinese researchers could only provide a theoretical answer to this question, since the solution and the techniques outlined by them require a 372-qubit computer. Though this does exist within the walls of IBM,  the Chinese researchers did not have this machine at their disposal. However, they did succeed in factoring a 48-bit (15-digit) number with a 10-qubit computer. At first sight, this may not seem like much of a breakthrough, but it should be noted that this is the largest number that has ever been factored using a generic algorithm. Not to mention the fact that it was possible to put a theory into practice. The question is whether it was possible to bridge the aforementioned gap. As the correspondence between [Bruce Schneier](https://en.wikipedia.org/wiki/Bruce_Schneier) – one of the iconic figures of IT security – and [Roger A. Grimes](https://www.amazon.com/stores/Roger-A.-Grimes/author/B001IQUMT4) – the author of several books on cryptography – revealed:\n\n>“Apparently what happened is another guy who had previously announced he was able to break traditional asymmetric encryption using classical computers…but reviewers found a flaw in his algorithm and that guy had to retract his paper. But this Chinese team realized that the step that killed the whole thing could be solved by small quantum computers. So they tested and it worked.”\n\nYou might think that the cryptographic apocalypse is here.\n\n## Keep Calm and Dig Deep\n\nThe basis of the Chinese researchers’ algorithm relies on [Claus Schnorr](https://en.wikipedia.org/wiki/Claus_P._Schnorr)'s factorization algorithm (not to be confused with [Shor’s algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm)). The aforementioned algorithm works well with smaller numbers – with which the researchers themselves tested it – but falls apart with larger values. It is precisely this limitation that the Chinese researchers claim to have overcome. However, they do not mention any details, and they have not been able to prove the complete theory in practice due to the lack of a quantum computer with sufficient capacity. As Schneier cited the situation on his blog:\n\n> “So if it’s true that the Chinese paper depends on this Schnorr technique that doesn’t scale, the techniques in this Chinese paper won’t scale, either. (On the other hand, if it does scale then I think it also breaks a bunch of lattice-based public-key cryptosystems.)”\n\nDoes the uncertainty remain until someone tries the algorithm on a sufficiently large-capacity quantum computer? Partially.\n\nThere are, in fact, some signs that cast doubt on the whole story. One of these is that the Chinese researchers failed to win the $200,000 prize offered by the [RSA Factoring Challenge](https://en.wikipedia.org/wiki/RSA_Factoring_Challenge), which goes to whoever can successfully crack a 2048-bit RSA key. Of course, you could say that they did not have the necessary hardware, but a letter to IBM to get the prize, even if it is shared, would have been certainly worthwhile. People drawn to conspiracy theories may ask why the Chinese state did not keep the discovery for itself and started pouring money into the development of a suitable quantum computer. This would obviously cost a very substantial amount, but would also bring a very substantial benefit. At the same time, there is also strong skepticism from the scientific side. [Scott Aaronson](https://en.wikipedia.org/wiki/Scott_Aaronson) – former researcher at MIT, now at the University of Texas – made a [devastating statement on his blog](https://scottaaronson.blog/?p=6957) about the Chinese paper. Aaronson, in his pieces of research, primarily focuses on quantum computing and complexity theory, perhaps the most important fields of science concerning our topic. His three-word review about the content of the publication was: “No. Just no.” He criticized the publication in a firm tone:\n\n\n> “Then, finally, they come clean about the one crucial point in a single sentence of the Conclusion section:\n> It should be pointed out that the quantum speedup of the algorithm is unclear due to the ambiguous convergence of QAOA.\n> “Unclear” is an understatement here. It seems to me that a miracle would be required for the approach here to yield any benefit at all, compared to just running the classical Schnorr’s algorithm on your laptop. And if the latter were able to break RSA, it would’ve already done so.\n> All told, this is one of the most actively misleading quantum computing papers I’ve seen in 25 years, and I’ve seen … many.”\n\nAaronson is not alone in his opinion: [many](https://www.linkedin.com/feed/update/urn:li:activity:7016808281847336960/) [others](https://www.linkedin.com/feed/update/urn:li:activity:7017366747691241472/) criticize the research on the same basis, including Peter Shor, who says:\n\n> “There are apparently possible problems with this paper.”\n\nIt should also be highlighted that the research-sharing platform ([arχiv](https://arxiv.org/)), where the Chinese study was published, [does not perform peer reviews](https://arxiv.org/about), meaning that the mere fact of publication does not mean much, especially in such popular fields as quantum computing and cryptography. \n\n## So, are we off the hook or not?\n\nEven if we are able to recognize all the [research paper mills](https://en.wikipedia.org/wiki/Research_paper_mill) – which must necessarily be expected in a popular and highly regarded discipline such as cryptography or quantum computing –  the harsh reality remains. Any encrypted data recorded today that uses a cryptographic process that does not withstand the challenges posed by quantum computers could become compromised in the not-too-distant future. As a result, it would be necessary to use algorithms that are thought to be secure against a cryptoanalytic attack by a quantum computer to mitigate the effect of the harvest-now-decrypt-later technique, as it cannot be eliminated. In the  case of a cryptographic problem that received great publicity, such as Heartbleed in 2014, the market reacted relatively quickly, although it was weeks before the error disappeared from the 100,000 most-visited pages. In other cases, which have not received as much publicity, it can take years, according to statistics from [Qualys Pulse](https://www.ssllabs.com/ssl-pulse/) . In other words, we cannot expect the introduction of post-quantum cryptography to happen much faster than this.\n\nThis is just like global warming: a problem that cannot be dealt with in the future when it becomes critical. It should be dealt with in the present. The similarity is striking if we consider the fact that scientists have been scaring people with horror stories about quantum computers for decades. What seemed like a theory for a while, has now become the reality. [IBM promises a one-thousand-qubit computer](https://www.science.org/content/article/ibm-promises-1000-qubit-quantum-computer-milestone-2023) by the end of the year, and [Google a one-million-qubit one](https://www.cnet.com/tech/computing/google-plans-to-build-a-practical-quantum-computer-by-2029-at-new-center/) by the end of the decade. The latter does not promise anything good, since it is only a question of data storage capacity – how much data can be accessed after RSA becomes breakable. The first to have machines with sufficient capacity will presumably be the still much-criticized technology giants, and the most powerful states. Lawmakers still call for encryption backdoors [from time](https://www.helpnetsecurity.com/2017/06/20/eu-encryption-law/) [to time](https://www.helpnetsecurity.com/2021/04/05/weak-encryption/), despite the [warnings](https://balasys.eu/blogs/weakened-encryption-is-a-silver-bullet-not-just-for-law-enforcement-agencies-but-for-cybercriminals) about the [serious risks involved](https://pfeifferszilard.hu/2021/02/25/cryptography-weakening-a-tale-of-the-law-abiding-criminal.html), but with such a technical breakthrough, they would not necessarily need to do so. However, this may have consequences that are difficult to foresee both for privacy and the outcomes of conflicts that are increasingly transferred to cyberspace.","date":"February 20, 2023","id":"Blogposts_35","short_description":"In a recent publication, Chinese researchers claim that there is an existing algorithm that, even with today's quantum computers, makes it possible to break the RSA algorithm, which is the fundamental basis of secure internet communication. At the same time, there are doubts about the reliability of the publication.","isEnglish":true,"isHungarian":false,"slug":"chinese-researchers-rsa-is-breakable-others-do-not-panic","title":"Chinese researchers: RSA is breakable. Others: Do not panic! "},{"author":"László Horváth, Pre-Sales Engineer at Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/code_1839406_1280_48de8cd8f8.jpg"},"content":"*WAF-as-a-service solutions are becoming an increasingly popular method for protecting websites and services running in the cloud. One significant advantage is the vendors' claim that security settings can be updated in time based on the data from incoming attacks that are caught. However, the question arises: how effective and inevitable are current WAFs and WAF-as-a-service solutions?*\n\nIt is essential to address this issue as injection attacks are a prominent feature in the periodic OWASP Top 10 list, ranking 1st in 2013 and 2017 and 3rd in 2021, after broken access control and cryptographic failures. \n\n\n## Autospear: the new generation of SQL attacks \n\nAt the Black Hat Asia conference in May, researchers from Zhejiang University in China presented a new automated SQLi method for testing and bypassing signature-based WAFs. The method consists of using algorithms to modify the code originally intended to be injected – which is detected and blocked by firewalls by default – until it cannot be detected using the negative security model. \n\nThe modifications were as follows: \n\n| MODIFICATION  | EXAMPLE  |\n| ---  | ---  |\n| Case Swapping  | or 1 = 1 → oR 1 = 1  |\n| Whitespace Substitution  | or 1 = 1 → \\tor1\\n=1  |\n| Comment Injection  | or 1 = 1 → /\\*foo\\*/or 1 =/\\*bar\\*/1  |\n| Comment Rewriting  | /\\*foo\\*/or 1 = 1 → /\\*1.png\\*/or 1 = 1  |\n| Integer Encoding  | or 1 = 1 → or 0x1 = 1  |\n| Operator Swapping  | or 1 = 1 → or 1 like 1  |\n| Logical Invariant  | or 1 = 1 → or 1 = 1 and 'a' = 'a'  |\n| Inline Comment  | or 1 = 1 → /\\*!or/ 1 = 1<br>union select → /\\*!union\\*/ /\\*!50000select\\*/  |\n| Where Rewriting  | where xxx → where xxx and True<br>where xxx → where (select 0) or xxx  |\n| DML Substitution  | or 1 = 1 → \\|\\| 1 = 1 <br>and name = 'foo‘ → && name = 'foo'  |\n| Tautology Substitution  | 1 = 1 → ‘foo’ = ‘foo’<br>‘1’ = ‘1‘ → 2 <> 3 <br>1 = 1 → (select ord(’r’) regexp 114) = 0x1  |\n\nThe point of the modifications, in this case, is that the SQL command will not change semantically, and the database server will be able to process it, but the signature-based protection can be bypassed. To do this, an algorithm is used that systematically maps which modifications can be run by trial and error and uses the feedback to design the code for the final attack. \n\nThe researchers tested the method on seven popular web application firewalls, four of which are available on Amazon Web Services as WAF-as-a-service. They focused on four types of requests (GET / GET(JSON) / POST / POST(JSON) and generated 10,000 unique codes from 100 known SQLi expressions. \n\nThe results suggest that WAF-as-a-service solutions can be attacked with high effectiveness, as there were vendors with 89% or more success using JSON payload. \n \n\n## Positive security model: protection against Autospear and other attacks\n\nThe positive security model has often been criticized for being more time-consuming and complex – and therefore more costly – to develop than the signature-based model. Still, it can provide much more effective protection against Autospear and similar attacks. With a properly designed and maintained API schema, the acceptable incoming data in a given field can be limited to the point where any modification that does not contain the expected data will immediately block the call. For example, in a userid field, you can specify precisely where and what characters are expected, their length, and composition. \n\nThis takes time and expertise, and needs to be tailored to the specific API in each case. It is not a switch that, when flipped, can give a false sense of security that you are protected against OWASP Top10 vulnerabilities. \n\nAnother severe criticism is that the positive security model gives too many false positives, though this problem can be avoided using expert-created and maintained templates and continuous feedback during testing. \n\nHowever, a proper API security solution can help you to build your positive security model effectively. It is essential to ensure proper logging is in place during the development and testing phase. This can help you picture what your core traffic consists of and what vulnerabilities exist. A positive security model also enables you to test existing – or possibly missing – traffic-based schemes under controlled conditions. You can provide appropriate feedback to your developers by filtering out any calls that may occur that do not conform to the scheme. This can be recorded in log files in a developer environment with accurate feedback without interrupting the call. In a live system, you can immediately cut off the call without feedback or send a misleading message to the attacker. ","date":"November 30, 2022","id":"Blogposts_33","short_description":"Web Application Firewalls (WAFs) are widely used to protect websites and APIs against various attacks, such as SQL injection (SQLi) and cross-site-scripting (XSS). ","isEnglish":true,"isHungarian":true,"slug":"weaknesses-of-signature-based-api-protection","title":"Weaknesses of signature-based API protection"},{"author":"Szilárd Pfeiffer, Security Engineer & Evangelist, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/ZT_Blog_balasys_6349a385158f9_1405296b55.jpg"},"content":"The Cybersecurity Tech Accord, throughout Cybersecurity Awareness Month in October, broke down the core elements of “Zero Trust” architecture in a blog series – Never Trust, Always Verify. The series featured expert voices from across Cybersecurity Tech Accord signatories analyzing what Zero Trust is, what is isn’t, and how to have an informed conversation to ensure your organization is employing best practices for security.\n\nSzilárd Pfeiffer, Security Engineer & Evangelist at Balasys, wrote about Zero Trust and strong authentication.\n\n### What is Zero Trust and why is it important?\n\nTraditional cybersecurity approaches focus on establishing a sound perimeter to keep malicious actors outside a network. This assumes that all users and resources inside the perimeter are trustworthy. In today’s world, however, resources are increasingly hybrid in their structure, and data are spread across an innumerable combination of devices, services, applications, and people. This makes security more complicated than simply keeping bad actors outside a network; good security means knowing more about who’s inside as well.  According to the Zero Trust Architecture’s principle guideline – never trust, always verify – no resource should be accessed until successful authentication and authorization have been achieved.\n\nWhile the Zero Trust security Model was first introduced in the 1990’s, it’s only become widely known and used in the past few years because, like many things, it is far easier said than done. But one thing is for sure: the improved security environment is worth the effort, and it begins with strong authentication. The Zero Trust security model is an approach to the design and implementation of information technology systems. The main concept behind the architecture is de-perimeterization, which refers to the removal of a boundary between an organization and the outside world.\n\n### The seven tenets of Zero Trust\n\nThe United States’ Cybersecurity and Infrastructure Security Agency (CISA) [has outlined the following principles](https://www.cisa.gov/sites/default/files/publications/CISA%20Zero%20Trust%20Maturity%20Model_Draft.pdf) in its Zero Trust Maturity Model:\n\n**1. All data sources and computing services are considered resources.**\n\nEven if the network is composed of multiple classes of devices, this tenant does not allow exceptions. In practice, there should be at least one policy enforcement point in the network where all the traffic goes through and where the policy can be enforced.\n\n**2. All communication is secured regardless of network location.**\n\nSecure communication and providing trust are no longer based on the location of an asset.\n\n**3. Access to individual enterprise resources is granted on a per-session basis.**\n\nAn evaluation should be made before giving access to a resource independently of whether the resource was previously permitted or not.\n\n**4. Access to resources is determined by dynamic policy.**\n\nThe policies should be generated as real time as possible and should always be appropriate to the attributes.\n\n**5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.**\n\nNo asset should inherently be trusted, and data integrity should be maintained at all times.\n\n**6. All resource authentications and authorizations are dynamic and strictly enforced before access is allowed.**\n\nAuthentication and authorization should always be rigorously checked at each access request before access is granted to a resource.\n\n**7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses this information to improve its security posture.**\n\nMaintaining and improving security posture is a never-ending circle: collecting and analyzing data are essential to the process.\n\nWhile there is no one definition for Zero Trust architecture, the major tenets of the approach, as described by CISA, make clear that strong authentication is at its foundation. And strong authentication needs to be a priority for all security architecture, as password issues are responsible for more than 80 percent of data breaches. And strong passwords alone are not enough. Organizations today require more robust protections to defend themselves against the latest threats. Though  more and more companies are investing in various strong/multifactor authentication methods, it has proven easier to purchase a solution than to effectively implement and introduce it across an organization. So how should organizations start to actually follow through in adopting strong authentication practices?\n\n\n## ALWAYS ENCRYPT AND ALWAYS ENCRYPT WELL\nThe ‘zeroth’ step in implementing strong authentication is reliable encryption. Zero Trust requires that enterprises never consider their private network as an implicit zone of trust. Assets on a network should always be handled as if an attacker was persistent on the system. As a result, access to resources should be granted in the most secure manner available. This entails not just authenticating all connections, but also encrypting all the traffic. Attackers are smart, and capable enough to eavesdrop on a network, analyze any unencrypted traffic to capture credentials to perform a well-structured attack later.\n\nIn the case of a private network or service, it is good practice to allow only the most secure cryptographic algorithms that provides [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy), such as [ECDHE](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) and [authenticated encryption](https://en.wikipedia.org/wiki/Authenticated_encryption), such as [Poly1305](https://en.wikipedia.org/wiki/Poly1305). Attacker toolchains – such as other software systems – often contain legacy parts that do not support the most modern mechanisms. This means that an exploit used against a service that can be accessed solely via encrypted channels, using the most modern algorithms, will fail before it can really begin, even if the attacker can access the system and has valid credentials, as the initiation of the encrypted connection will fail. This approach also has other indirect benefits. Using state-of-the-art encryption increases security as connection failure events can be reported as suspicious behaviors as part of “real-time monitoring,” another requirement of Zero Trust. Beyond this, advanced encryption also helps us identify our own legacy or “shadow” systems that cannot support the most modern forms of encryption, meaning they should either be accessed through a middleware device or be sunset altogether.\n\n\n## AUTHENTICATION IS ABOUT IDENTITY, NOT METHODS\nJust like there is no reliable authentication without encryption, there is no authorization without reliable authentication. Zero Trust requires strictly enforced authentication and authorization before resource access. Unfortunately, security experts sometimes focus on methods instead of identity. Passwords, certificates, tokens, or biometrics are just methods, they are not the identity itself.\n\nFor instance, spyware can collect login credentials by harvesting from the databases of pawned sites, especially when users use their company email addresses for private purposes. Meanwhile, simpler passwords can be brute-forced to be discovered. If security is compromised, the password can no longer prove identity.  You might think that a more modern and sophisticated method – such as a digital certificate – could solve the issue of simple passwords, but at the end of the day the strength of the certificates depends on the strength of the password that protects the certificate’s private key. If an attacker can compromise a protecting password, the authentication based on the certificate is also compromised.\n\n[Multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) (MFA, or 2FA) has not become so popular for nothing, and security experts today encourage both individuals and companies to use at least a second factor in authentication. However, MFA also has weak points in addition to its significant benefits. A typical [time-based, one-time password](https://en.wikipedia.org/wiki/Time-based_one-time_password) (TOTP) either expires after a minute or is used as part of successful authentication. This means that even if an attacker acquires the actual value, it cannot be used for subsequent authentications. Unfortunately, this does not protect against [website spoofing](https://en.wikipedia.org/wiki/Website_spoofing), which can prompt a user to provide both their password and the TOTP on the spoofed authentication form. Using the intercepted credentials, the attacker can then authenticate in the name of the victim.\n\nA more convenient, but less secure, second factor in MFA is [“push-based” authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication#Mobile_phone-based_authentication) where, following a successful password-based authentication, the user confirms the login by clicking “Yes, it was me” in a push notification received on their mobile device. However, if an attacker can compromise the password, several login attempts can be made that cause several push notifications on the mobile device of the victim. Just one confirmation in error that occurs either accidentally or through getting tired of the spoofing [(MFA fatigue attack)](https://www.securityweek.com/high-profile-hacks-show-effectiveness-mfa-fatigue-attacks) is enough for the attacker to get into the system. It is also important to remember that a mobile-based second factor cannot be any more secure than the protection of the mobile device itself. If the mobile device isn’t locked, we risk the sense of the second factor, and this is the case if confirmation can be done without unlocking, or the locking pattern is simple, [predictable](https://arstechnica.com/information-technology/2015/08/new-data-uncovers-the-surprising-predictability-of-android-lock-patterns/), or vulnerable to [smudge attack](https://en.wikipedia.org/wiki/Smudge_attack).\n\nTo make a long story short: MFA is an essential best practice, but no matter how perfect a solution may seem, security awareness is still essential.\n\n\n## AUTHENTICATION IS NECESSARY, BUT NOT SUFFICIENT\nZero Trust Network Architecture requires both encryption and authentication, but these are means, not an end in and of themselves. According to the [National Institute of Standards and Technology (NIST) in a special publication on Zero Trust architecture](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf), both authentication and authorization should be strictly enforced every time before access is granted to any resources inside or outside of the private network, in line with the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). This means that the classification of a resource should also vary the conditions of the resource access. Depending on the observable state of client identity, the requesting assets, or other behavioral and environmental attributes, various levels of access can be granted for a resource.\n\nThe principle of least privilege (PoLP), also known as the principle of minimal privilege (PoMP) or the principle of least authority (PoLA), requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.\n\nFor instance, under certain circumstances, strictly “read-only” access may be granted to a particular resource, but upon further authentication “read-write” access can be provided as well. The situation reflects approaches to physical security, where entering physical environments with higher classification requires additional authentication. In terms of network and data security, access to data should mirror physical security considerations and authentication requirements for access to a location. In this dynamic, authentication is not just a single step – pass through the doors and you’re in – but rather a repeatedly executed task of the policy enforcement process based on what is being accessed and how.\n\nThe first tenet of Zero Trust says that all computing services are considered resources. Authentication services should be considered as resources, meaning that access should be granted taking the least privilege principle into account. It means that the number of authentication requests, including successful and unsuccessful, should not exceed a certain number. Rate limiting unsuccessful authentication requests helps to prevent brute-force attacks against the first factor of the authentication, such as a password. However, this does not diminish the importance of choosing properly secure passwords. Rate limiting successful authentication requests helps to avoid the compromise of the second factor after the first factor has already been compromised. For instance, an MFA fatigue attack is hardly feasible if the number of successful authentication requests is limited. Zero Trust requires monitoring and measuring the security posture of all owned and associated assets, meaning that exceeding the rate limit should be monitored and could trigger the deactivation of a user account that is suspected to be compromised. This is how identity handling becomes dynamic, something which is required at the optimal level of maturity in the [Zero Trust Maturity Model](https://www.cisa.gov/sites/default/files/publications/CISA%20Zero%20Trust%20Maturity%20Model_Draft.pdf).\n\n\n## HUMAN FACTOR IS UNAVOIDABLE IN AUTHENTICATION\nWhile trying to achieve the higher and higher levels of Zero Trust maturity, we should not forget about the weakest link in all security system chains: humans. Security is often contrary to comfort, yet discomfort is usually also contrary to security. Even the trendiest, most cutting-edge , methods can have weak points that attackers can successfully exploit while the most traditional methods might work effectively under such circumstances. Not surprisingly, users tend to bypass security systems if the discomfort they experience exceeds a certain level. Bothering users with [frequent password changes](https://learn.microsoft.com/en-us/archive/blogs/secguide/security-baseline-draft-for-windows-10-v1903-and-windows-server-v1903) is a particularly good example of this. Users who are forced to frequently change their passwords often fall into two kinds of bad habits for security when trying to remember their passwords. The first is writing it down where others can see it, and therefore steal it. The second is that making memorable but predictable alterations to their existing password to fulfill the password policy requirements.\n\nA conventional authentication method such as a password can be secure, but its security level does not depend on the expiry period. – rather, it depends on the entropy. The easier it is for a user to remember a strong password, the likelier it is they will use it. Security is about minimizing risks that cannot be taken without cooperation. High security requirements are good, but followable security rules that are in line with the risk are the best.\n\nThis article was originally published on the [Cybersecurity Tech Accord blog](https://cybertechaccord.org/strong-authentication-no-zero-trust-network-without-strong-authentication/). ","date":"November 3, 2022","id":"Blogposts_32","short_description":"A “Zero Trust” cybersecurity model has been one of the most important innovations in organizational risk management in recent years. It constitutes a fundamental shift in mitigating risk, but one that is still not widely adopted or even understood.","isEnglish":true,"isHungarian":true,"slug":"no-zero-trust-network-without-strong-authentication","title":"No Zero Trust Network without strong authentication"},{"author":"Dániel Bagó, Product Marketing Manager, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/carlos_muza_hpj_Sk_U2_UYSU_unsplash_aa69fd37ce.jpg"},"content":"**What is a banking API?**\n\nOpen banking is the practice of securely sharing financial data, subject to customer consent. The exchange of data between the bank and authorized third parties (such as financial institutions, fintech companies, and enterprises that are not necessarily active within the financial sector at present) is enabled via Application Programming Interfaces, or APIs.\n\nAPIs enable the communication of different applications with each other by regulating how different software components interact. We use dozens of APIs each day – in mobile bank apps, in movie streaming services, on various websites, and in electric cars.  APIs grant companies opportunities to provide easy-to-use and intuitive services to their customers.\n\nBanking APIs help financial institutions provide modern web-based services and mobile apps to their customers. Historically, banks had proprietary services and offered them only through their own channels. Thanks to the adoption of PSD2 (Payment Services Directive) by the European Parliament in October 2015, this situation has changed forever: PSD2 promoted the development and use of innovative online and mobile payments through open banking solutions.\n\nOpen banking APIs allow third parties – like Revolut and Wise– to access account information and initiate payments. These new companies were crucial for developing new apps and services for the customers of traditional banks on top of bank infrastructure. Their impact can be compared to the role of Google Maps API – thousands of mobile services now rely on geolocation data provided by Google Maps. As the number of users of only these two fintech companies has exceeded 22 million by 2022, it is not an exaggeration to say that open banking APIs have successfully shaken the financial system, and transformed how incumbents interact with their consumers, with other banks, and with fintech companies.\n\nAlthough open banking has brought many advantages to customers, it is not without risks:\n\n\n- Open banking solutions are popular targets for cybercriminals. Given that the largest cybercriminal groups have begun to operate as professionally as multinational companies in recent years, we can confidently say that a large data breach could happen at any time\n\n\n- Freemium business model threatens privacy – most customers do not understand how sharing too much personal data may come back to bite them. For example, healthcare-related information may make personal insurance more expensive\n\n\n- Malicious actors may use open banking information to trick customers or companies with phishing scams\n\n\n- Traditional web application defense systems such as WAFs (Web Application Firewalls) are insufficient to fully protect APIs, as API attacks are logic-based, rather than rule-based. It is not a coincidence that OWASP released a Top 10 list targeting API Security in 2019 to expand the original OWASP Top 10 that began publication in 2003. However, many organizations still have a false sense of security based on security products that were not designed to protect against API-attacks\n\n**What are the benefits of Open Banking APIs?**\n\nOpen banking APIs bring many advantages to customers:\n\n\n - They can choose from a wide variety of service providers; they are not bound to their bank\n\n\n - Wide variety is true for the available services as well; fintech companies offer many services that were previously unavailable\n\n\n - API-based mobile banking apps enable a ’streamlined’ banking experience; customers do not need to go into their banks; they can manage almost all their requests and tasks with their mobile phones\n\nBut open banking is also beneficial for banks and third-party providers:\n\n\n - Financial organizations get the potential to increase their revenue streams\n\n\n - Open banking makes it possible to create revenue-sharing ecosystems: banks give customers access to 3rd party services while taking advantage of every new subscriber\n\n\n - Banks may open their infrastructure and provide core services to fintech companies on a Backend-as-a-Service (BaaS) basis\n\n**Examples of Open Banking APIs**\n\nThousands of banks and other financial companies have built various services in the last few years. Here are a few examples:\n\n_BNP Paribas_ is a French international banking group. It is the second largest banking group in Europe, with 190,000 employees. BNP Paribas’s Open Banking Portal enables developers to test and use various APIs in production free of charge. It offers a wide variety of services in addition to the ’compulsory’ PSD2 ones (Account Information, Payment Initiation, and Availability of Funds), such as smart derivatives API or net asset valuation API.\n\n_Barclays_ is a British multinational universal bank headquartered in London. It launched its Open Banking initiative in 2018 and offers various services beyond account information or payment initiation, such as an ATM Locator and Branch Locator.\n\n_DirectID_ is one of the earliest open banking pioneers to use open banking data to offer different credit and risk decisioning services, such as bank account verification, portfolio risk management, and SME financial health.\n\n \n\n**Regulations**\n\nAlthough open banking brings advantages for incumbent financial institutions too, it also fosters competition – which is why regulators had to be the key drivers of open banking’s spread. As we outlined earlier, the most important regulation – and stimulant – around open banking is the _Directive of the European Parliament and of the Council (EU) 2015/2366 of 25 November 2015 on payment services in the internal market_, i.e. PSD2. PSD2 introduced increased competition and innovation into the financial services sector and successfully gave birth to several new customer-centric payment services changing the classic bank-customer relationship forever.\n\nBut PSD2 is not set in stone: the European Commission has already announced and launched a comprehensive review of the Directive – the consultation period ended in August, and the adoption of the modified regulation is planned for Q4 2022.\n\nPSD2 is not the only good example available of open banking. In the UK, the Competition and Markets Authority (CMA) set up the Open Banking Implementation Entity in 2016 to foster innovation and competition in the retail banking sector. In recent years, the open banking ecosystem has enabled customers and SMEs to share their current account information securely with third party providers, who then use that data to tailor their apps and services to people’s specific financial circumstances.\n\nThe UK and the EU are the most developed countries in terms of open banking, and their development is accelerating further. But without regulations like the PSD2, other countries with advanced banking systems – such as Japan, Canada, or the United States – are only opening their banking services very gradually.\n","date":"October 28, 2022","id":"Blogposts_31","short_description":"The practice of securely sharing financial data, subject to customer consent, through banking APIs gave birth to hundreds of new applications that were previously unavailable.","isEnglish":true,"isHungarian":true,"slug":"the-role-of-ap-is-in-open-banking-initiatives","title":"The role of APIs in Open Banking initiatives"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/nahel_abdul_hadi_flha0_Kw_Rr_Rc_unsplash_00d94947d5.jpg"},"content":"The Russia-Ukraine war has already taught cybersecurity practitioners many lessons, but as we move forward in time, there are more and more seemingly less significant issues to address that have long-term importance, such as API and cloud security. How do these two areas emerge in the shadow of armed conflict? As is well known, the IT Army of Ukraine, a volunteer group of Ukrainian hackers and cybersecurity professionals, strongly supports its country in cyberspace operations. One of their first successful operations, back in late February, was an attack on the Sberbank API, which resulted in [the bank being rendered inaccessible](https://techcrunch.com/2022/02/27/ukraine-takes-the-resistance-to-cyberspace-assembling-an-it-army-to-hack-sites-from-russia-and-its-allies-calls-on-tech-leaders-to-get-involved). But we could also mention the embargo of several technology companies, including SAP, against Russia, which made the German company's installations inaccessible after [banning Russian users from cloud installations](https://www.nytimes.com/2022/04/20/business/sap-germany-russia.html).\n\nMeanwhile, the government of Ukraine has taken serious steps to move the country, and specifically the government itself, from traditional IT infrastructure to cloud solutions. Back in 2021, the Ukrainian government signed an agreement with Amazon for the widespread deployment of cloud-based solutions, which at the time was seen as a step towards the country's [digital transformation](https://odessa-journal.com/ministry-of-digital-transformation-and-amazon-to-cooperate-to-accelerate-the-development-of-cloud-technologies-in-ukraine/). In 2022, however, the cloud is the safe haven for Ukrainian government IT, as in March President Zelensky [signed a decree](https://sk.ua/news/cloud-technologies-and-data-centres-new-regulation-in-ukraine/) allowing certain elements of the national data assets to be stored with foreign cloud providers. The resilience of digital data and infrastructures can therefore be significantly enhanced by the use of the cloud, and this seems to work in practice, as the Ukrainian administration has remained operational despite the fact that critical infrastructures are constantly under attack, both physically and in cyberspace.\n\nThe cloud is therefore both a dependency and an opportunity. The experience of the war is likely to lead more governments to seriously consider whether it might be worth taking advantage of the increased security offered by the cloud and accepting the technological dependency that it entails. In the meantime, technology vendors are increasingly reluctant to abandon cloud services, as smart devices, Big Data storage and processing, the use of artificial intelligence, and even automation cannot be achieved without cloud use. As a result, there is no question that the cloud is the way forward, even for more conservative organizations. At the same time, this is completely transforming the organization's approach to information security, and although some best practices have been in place for a decade, there is a lot to relearn and rebuild.\n\nFirst and foremost, the move to the cloud should always be guided by the [Zero Trust principle](https://balasys.eu/en/solutions/zero-trust/). This means that, while ever more organizations are consigning their partial or even full infrastructure to a cloud provider, experience shows that improper access control of cloud services is a high-risk factor. This dynamically changing resource is most often configured via APIs, often in an opaque manner, not in accordance with organizational policies (if they have organizational policies at all). It means that attackers, be they cybercriminals or state actors, can very often exploit these deficiencies to gain access to sensitive data or to damage otherwise well-functioning infrastructures. The [Balasys Proxedo API Lifecycle Platform (PALP)](https://balasys.eu/en/proxedo-api-lifecycle-platform) helps, among other things, to ensure that these resources running in the cloud are also secure enough to function. Even in times of cyber warfare.\n","date":"October 10, 2022","id":"Blogposts_29","short_description":"The Russia-Ukraine war has already taught cybersecurity practitioners many lessons, but as we move forward in time, there are more and more seemingly less significant issues to address that have long-term importance, such as API and cloud security.","isEnglish":true,"isHungarian":false,"slug":"api-and-cloud-security-in-times-of-cyber-warfare","title":"API and cloud security in times of cyber-warfare"},{"author":"Krasznay Csaba, a Kiberbiztonsági Kutatóintézet vezetője","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/nahel_abdul_hadi_flha0_Kw_Rr_Rc_unsplash_00d94947d5.jpg"},"content":"Az orosz-ukrán háború számos tanulsággal szolgált már eddig is a kiberbiztonság területén dolgozók számára, de ahogy haladunk előre az időben, egyre több olyan, látszólag kisebb jelentőségű, ámde hosszú távon nagyon fontos üggyel is foglalkozni kell, mint például az API és a cloud biztonság. Hogyan kerül elő a fegyveres összecsapások árnyékában ez a két terület? Mint az közismert, az IT Army of Ukraine nevű, ukrán hackerekből és kiberbiztonsági szakemberekből álló önkéntes csoport erőteljesen támogatja hazáját a kibertéri műveletek során. Az egyik első sikeres tevékenységük, még február végén, a Sberbank API elleni támadása volt, melynek eredményeképp [a bank elérhetetlenné vált](https://techcrunch.com/2022/02/27/ukraine-takes-the-resistance-to-cyberspace-assembling-an-it-army-to-hack-sites-from-russia-and-its-allies-calls-on-tech-leaders-to-get-involved). De említhetném számos technológiai cég, így az SAP Oroszország elleni embargóját is, melynek során a német cég telepítései váltak elérhetetlenné az orosz felhasználók [felhős telepítésekről való kitiltása után](https://www.nytimes.com/2022/04/20/business/sap-germany-russia.html).\n\nEközben Ukrajna kormányzata komoly lépéseket tett annak érdekében, hogy az ország és konkrétan a kormányzat felhős megoldásokra váltsa hagyományos IT infrastruktúráját. Az ukrán kormány még 2021-ben kötött megállapodást az Amazonnal a cloud-alapú megoldások széles körű elterjesztése érdekében, mely akkor elsősorban az ország [digitális transzformációját](https://odessa-journal.com/ministry-of-digital-transformation-and-amazon-to-cooperate-to-accelerate-the-development-of-cloud-technologies-in-ukraine/) szolgáló lépésnek tűnt. 2022-ben azonban a felhő jelenti a biztos menedéket az ukrán kormányzati informatikának, hiszen márciusban Zelenszkij elnök aláírta azt a rendeletet, melynek értelmében akár a nemzeti adatvagyon bizonyos elemeit is tárolhatják külföldi [cloud szolgáltatónál](https://sk.ua/news/cloud-technologies-and-data-centres-new-regulation-in-ukraine/). A digitális adatok és infrastruktúrák ellenállóképessége tehát jelentősen növelhető a felhő használatával, és ez a gyakorlatban is működőképesnek látszik, hiszen az ukrán közigazgatás működőképes maradt annak ellenére, hogy a kritikus infrastruktúrákat folyamatosan érik fizikai és kibertérbeli támadások is.\n\nA felhő tehát egyszerre függőség és lehetőség. A háborús tapasztalatok alapján valószínűleg egyre több kormányzat fog komolyan elgondolkodni azon, hogy érdemes-e a felhő jelentette magasabb fokú biztonságot igénybe venni és elfogadni az ezzel járó technológiai függést. Eközben a technológiai gyártók egyre kevésbé teszik lehetővé a felhőszolgáltatások mellőzését, mivel az okoseszközök, a Nagy Adatok tárolása és feldolgozása, a mesterséges intelligencia használata vagy éppen az automatizálás jelenleg nem megoldható felhőhasználat nélkül. Nem kérdés tehát, hogy még a konzervatívabb szervezetek számára is a felhő az irány. Ez viszont teljesen átalakítja a szervezet információbiztonsági hozzáállását és bár már egy évtizede vannak jó megoldások, újra kell tanulni és építeni sok mindent.\n\nAz első és legfontosabb, hogy a felhőre váltás minden esetben a [zero trust elv](https://balasys.eu/en/solutions/zero-trust/) mentén történjen. Ennek értelmében, bár a felhőszolgáltatásokra manapság egyre többen bízzák rá a részleges- vagy akár teljes infrastruktúrát, a tapasztalatok alapján magas kockázatot jelent a felhőszolgáltatások nem megfelelő hozzáférés-kezelése. Ezt a dinamikusan változó erőforrást a leggyakrabban API-kon keresztül állítják be, sokszor átláthatatlanul, nem a szervezeti szabályoknak megfelelően  (ha egyáltalán van kidolgozott szabályzat). A támadók, legyenek azok kiberbűnözők vagy állami aktorok, nagyon sokszor ezeket a hiányosságokat kihasználva férnek hozzá a féltve őrzött adatokhoz vagy tudnak kárt tenni az egyébként kiválóan működő rendszerben. A [Balasys Proxedo API Lifecycle Platform (PALP)](https://balasys.eu/hu/proxedo-api-lifecycle-platform/) többek között abban nyújt segítséget, hogy ezek a felhőben futó erőforrások is kellően biztonságosan működhessenek. Akár a kiberháborúk időszakában is.\n","date":"October 10, 2022","id":"Blogposts_30","short_description":"Az orosz-ukrán háború számos tanulsággal szolgált már eddig is a kiberbiztonság területén dolgozók számára, de ahogy haladunk előre az időben, egyre több olyan, látszólag kisebb jelentőségű, ámde hosszú távon nagyon fontos üggyel is foglalkozni kell, mint például az API és a cloud biztonság.","isEnglish":false,"isHungarian":true,"slug":"api-es-cloud-biztonsag-a-kiberhaboru-idejen","title":"API és cloud biztonság a kiberháború idején"},{"author":"Szilárd Pfeiffer, Security Engineer & Evangelist, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/technology_concept_cyber_security_internet_networking_c10f74694a.jpg"},"content":"This presentation was given on 9 June 2022, at the Balasys API Meetup. You can re-watch Szilárd’s presentation (in Hungarian) [here](https://www.youtube.com/watch?v=K8duwLr2auc).\n\n## The importance of APIs\nGartner says managing APIs will be one of the most highlighted areas of the future, if it is not today. There are 115 million attempts a day to compromise APIs. But what would be the solution? There are many advice on the Internet about how APIs should be handled and what security considerations are worth considering. According to Szilárd, the advice given to protect APIs are not far from the Zero Trust security principle, the methods can quite be incorporated into it.\n\n## Principles of the Zero Trust security concept - Is Zero Trust Architecture the answer to API security challenges?\nApplying the principles of Zero Trust to the world of APIs, we get the following rules:\n- All data sources and computing services are considered resources. We need to be aware of all the APIs in the system. In addition to production APIs, all functions of both tester and developer APIs must be recorded.\n- All communication is secured regardless of network location. Under the Zero Trust, this applies to both external and internal networks.\n- All resource access is preceded by authentication. In a sense, even public APIs have authentication, as far as the IP address can be considered as such.\n- Each resource access must be assessed individually.\n- All resource access must be done on a minimum authorization basis. Everyone has access only to what they are entitled to, and only in the volume and forms to which they are entitled.\n- Enterprises must monitor and measure the integrity and security posture of all owned and associated assets. This means not only monitoring behavior, but also interpreting the lifecycles of systems and APIs together.\n\n## Protection against OWASP Top 10 threats via Zero Trust principles\n### Everything should be treated as a resource.\nThe API inventory needs to be approached from two sides.\n\n**1. What API accesses we offer to our customers and users.**\n\nWe need to be aware of developer, tester, staging, and production systems one at a time when creating an inventory. It is necessary to take stock of where they are and what access we provide towards them. \n\nA security by obscurity approach in this regard is that „what we don't publish, what is not supposed to be known, can be considered as if it doesn't exist”. This path is fruitful only for attackers, not for defenders, as discovering APIs is not as difficult as people might think. Monitoring certificate transparency and requests, even guessing API endpoints, can lead to results even in case of not published APIs.\n\n\nAnother security concern is the lifecycle of APIs. In an environment, there are APIs that have expired in principle, but in practice there are still some incomplete or non-patched servers running them. Thus, these are easily exploited by attackers.\n\n**2. What APIs do we use? - Problem with the shadow API.**\n\nIf we do not know exactly what APIs we are using, we cannot handle the situation. The security by obscurity related saying is that „this is practically someone else’s problem”. Not surprisingly, this is not a purposeful mindset, as any vulnerabilities present in an API we use can affect the system as well.\n\n### All resource access is performed on an encrypted channel.\nThe next step, which usually happens during an attack, is the discovery with which we try to get information about the given system. The antidote to passive detection can be encryption. The approach that the internal network is immediately trusted, so there is no need for encryption, is no longer present, as a significant proportion of attacks come from within. The goal of attackers is to turn an external attack into an internal attack, because if the internal network is not secured properly, a lot of information falls into their lap.\n\n### All resource access is preceded by authentication.\nAttackers usually try to impersonate others and make requests to the system on behalf of them. Fortunately, completely missing authentication is rare these days, but from time to time it still occurs that authentication is not necessary on an internal network. Existing, however weak authentication often occurs when a company develops its own method, assuming that the self-developed authentication is not known to anyone, so it is not possible to crack it. In keeping with the three principles of cryptography — don’t make your own, don’t make your own, by no means make your own — it’s no surprise that security professionals do not recommend this concept either. Compromised authentication occurs when there is good quality authentication in principle, but it does not work in practice, so it is important to test the operation continuously.\n\n### Each resource access is evaluated individually.\nAttackers try to access resources other than those to which they are entitled. In addition to the much-mentioned authentication, authorization also plays a key role: we must follow the principle of least-privileged access, so that a given user does not have access to more or different information than the level of authorization allows.\nReplacing an object ID is a simple but effective way, because even if you pay attention to the fact that the IDs are not continuous in a system, they can be guessed quite well by an experimental method, especially if there is a predictable methodology for allocating the IDs.\n\nAnother typical method is to change the user ID. When an attacker has logged in as a user, the goal is to identify itself as a privileged user. Security by obscurity solution is that the privileged user does not have a specific ID. The approach to Unix systems provides a solution to this problem. Everyone knows that the root user ID is zero, however, every time someone wants to perform something on the system as the root user, authorization is needed.\n\nIt is common for attackers to access APIs in ways that we would not necessarily expect. A typical pattern is that in the case of a query, the system returns an unnecessarily large set of data based on that the client side is filtering the information anyway, so the users only see what their authorization allows. An attacker typically performs queries using an automated tool and analyzes the raw format, which includes information that the system did not originally intend to provide.\n\nThe reverse is when unsolicited data is entered into the system. If the authorization works by authorizing not only the individual objects but also the fields within it, this problem can be eliminated.\n\nIt is also to be expected that attackers will attempt to invoke API endpoints that we thought were not public. Because the nomenclature of IT systems is mainly the same, it is relatively easy to guess the details of an API and its structure using a guessing method.\n\nAlthough we guarantee system authentication and authorization, we are still not secure. Even if we log down that an attack has taken place, we are still vulnerable, especially when an attacker tries to get logs into the system that it is not prepared for. To eliminate the problem, the monitoring must be supplemented so the system can react to certain types of errors, e.g. with rate limiting.\n\nMonitoring occurs not only in operating systems, but also in the lifecycles of them. You need to be aware of what version of API endpoints have reached the end of their lifecycle. These types of access should be kept to a minimum.\n\nIn summary, the consistent application of the key phrase of the Zero Trust principle - **Never trust, always verify** - is not paranoia, but a preparation for the most typical attack patterns.\n\n","date":"August 4, 2022","id":"Blogposts_28","short_description":"There is really nothing new under the sun: APIs are secured by exactly the same precautions as anything else you publish on the internet.","isEnglish":true,"isHungarian":true,"slug":"szilard-pfeiffer-api-security-there-is-nothing-new-under-the-sun","title":"API security: There is nothing new under the sun"},{"author":"Gábor Pék, CEO of Avatao","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/coding_man_9d60b37107.jpg"},"content":"This presentation was given on 9 June 2022, at the Balasys API Meetup. You can re-watch Gábor’s presentation (in Hungarian) [here](https://www.youtube.com/watch?v=zD1JwflkLRs).\n\n##XSS? Trusted Types?\nIt is essential to look at Trusted Types and Cross Site Scripting (XSS) when taking stock of ongoing developments in the IT world.\nXSS is a relatively popular term. During XSS attacks, malicious scripts are injected into otherwise benign and trusted websites. According to the HackerOne security platform and hacker program, 23% of all vulnerabilities transmitted through bug bounty platforms are XSSs.\nIn one of his speeches in 2018, Mario Heinrich, CEO of Cure53, declared that “XSS is dead. We just don't get it.” This means that though the tools needed to mitigate XSS are available, developers lack the intention to implement them. However, he acknowledged that it is not necessarily possible to cover every single XSS with the available tools, so there are XSSs that are still out there and do need to be taken care of.\n\nA typical trend in the development of web technologies is the increasing preference for the client side, which has meant that server-side templating has been overshadowed. Developers are trying to make sure that the logic for single-page applications runs on the browser side, which means that the browser is the one to solve the problems.\nAnother observable phenomenon is the growth of the JavaScript code base. This means that Document Object Model (DOM)-based XSS will also grow as the medium available for it.\nThe essence of an XSS attack, as the name implies, is to achieve scripting across sites. This creates an opportunity for users to be redirected from one page to another or to steal data with malicious intent.\nIt is well known that there are excellent solutions for server-side-based templating, such as CSP and nonce-based CSP, but the question remains of what options the DOM API offers. The API provides roughly 60 DOM sinks that make it possible to override traditional behavior when assigning values. If they become controllable in any way for an attacker, it will result in a DOM XSS.\n\n##Trusted Types\nDuring a six-year research period, Google introduced Safe Types in its core services. As a result, they noticed a drastic reduction in DOM XSS – in fact, the company has now managed to eliminate it completely. The experiment was considered ready to be opened to the public. As a result, Trusted Types was born, though the standard is still officially a work in progress.\nAccording to Trusted Types, not only string assignment is possible, but an object can also be specified as a value. And if you can specify an object as a value, you can also define trusted objects. This contribution enables the DOM API to accept solely and exclusively trusted values. Defining a policy to create a trusted object is essential, which means that the Trusted Types policy receives a string as input and returns an object that has already been sanitized by it. Policy-based correction is enforced by the browser, so there is no option to specify exceptions.\n\n##Why is this beneficial?\n*Each value assignment that is placed in the DOM is validated*, as only trusted objects can be placed into it.\nMoreover, *it drastically simplifies code review.* It is no longer necessary to manually review the code, since items and security measures that are centralized in the policy and deemed safe in advance have already been reviewed. In simple terms, if the policy file is okay, everything will be fine.\n\n##Trusted Types case study: Avatao\nGábor and his team at Avatao tested how Trusted Types is able to function within a relatively large code base. In their case, research and implementation took roughly 32 hours.\nTrusted Types were warmly received in Chromium-based browsers, while other types of browsers had to be experimented with with polyfills. For non-Chromium-based browsers, Avatao claims the technology is still a bit immature, but the DOM API and DOM library are expected to be supplemented with the parameters needed for successful implementation in the foreseeable future.\n","date":"August 3, 2022","id":"Blogposts_27","short_description":"XSS, or cross site scripting, is one of the most widespread security problems today, as confirmed by statistics from bug-hunting companies such as Hackerone. ","isEnglish":true,"isHungarian":true,"slug":"gabor-pek-trusted-types-a-world-without-xs-ss","title":"Trusted Types: A world without XSS"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/cyber_attack_with_unrecognizable_hooded_hacker_using_virtual_reality_digital_glitch_effect_96bcf7bdb8.jpg"},"content":"The presentation that this blogpost discusses was given on 9 June 2022, at the Balasys API Meetup. You can re-watch Csaba’s presentation (in Hungarian) [here](https://www.youtube.com/watch?v=GuO67x8lO8k).\n\n\n## Cyber warfare? Cyber wars?\nYou may be wondering how cyber warfare is related to APIs, or what exactly cyber warfare is in the first place. Whereas in the past many researchers had only vague ideas about cyber warfare, today we have experienced cyber warfare in our own neighborhood. It could be said that life has kicked the door down on science. While what the potential for the events that have been occurring since 24 February 2022 was known to the experts, the conflict was not anticipated.\n\nAccording to the definition of cyber warfare and cyber war, operations in cyberspace are called upon to contribute to the supremacy in cyber space among the parties involved. With this superiority, the belligerent party, in addition to being able to overcome its opponent, serves and supports the other dimensions of warfare — land, water, air, and outer space.\n\nCyber warfare has been under development for a long time, going through many stations before it escalated to the level of cyber wars. It was even doubtful whether it would be possible to reach the level of genuine cyber warfare.\n\nConsidering the present situation, attacks on critical infrastructures necessary for the functioning of states and subsequent loss of human life have been anticipated and foreseen. This was also confirmed by the fact that Russia was suspected of developing cyber weapons and systems related to them.\nHowever, we have not seen much of an example of cyber weapons in recent years, as a DDoS or a sophisticated zero-day used for espionage is not – or not necessarily – considered a cyber weapon. The only exception was the malicious code NotPetya, more commonly known as the WannaCry ransomware.\n\n## Aspects of the Russo-Ukrainian war\nPublic opinion and researchers therefore expected that cyber weapons would eventually be present in the war, and that this would eventually lead to control of cyberspace. However, malicious codes are not currently the biggest problem.\n\nThe cyber operations of the Russo-Ukrainian war can be assessed from four points of view: domination of the information sphere, attacks on civilian and government IT systems, operations on critical infrastructures and military cyber operations. \n\nThe domination of the information sphere is the most spectacular front between the two countries. It means power over information and cognitive space to make society believe the narratives conveyed and represented by states. The Russian narrative has gained ground in much of Eastern Europe, while the Ukrainian narrative is predominant in Western Europe.\n\nOf course, in the background, plenty of conventional forms of attack can be identified. The opposing sides are attacking each other’s civilian and government IT systems, though surprisingly Russia has largely been a victim of these attacks. It can be said that building offensive capacity is much easier than defending the information systems of an entire country.\n\nCyberspace operations attacking Ukraine’s critical infrastructures can be found, but the results have fallen far short of preliminary expectations. Russia typically uses armed force successfully to destroy or render inoperable its opponent. In contrast, there are several cyber attacks dedicated against Russia that have achieved their intended purpose but have not come to light due to structured control over the information and cognitive space. Moreover, the use of civilian infrastructure and resources in warfare is common in military cyber operations.\n\n## Hacking? APIs?\nBelligerent states have begun to use the cloud more intensively than ever before. The Telegram channel used to recruit and coordinate the Ukrainian civilian IT army was used to call for attacks on the Russian Sberbank APIs, which has been proven successful and made the bank’s APIs unavailable. For attackers, the choice was an excellence target, as the FinTech realm operates through APIs, and banks form an important role in people’s everyday lives, which means that temporary or permanent interoperability causes high levels of disruption. In addition, due to the sanctions imposed on Russia, an increasing number of foreign IT service providers have withdrawn their support for various licenses, causing some difficult moments for many Russian companies.\n\nIt is obvious that managing the cloud is becoming of key importance in the conflict. The Ukrainian state placed its national data assets into the cloud before the war broke out. Under the agreement with Amazon Web Services, the company provided support for the transition, and the same opportunity was made easily available to Ukrainian companies as well. With the onset of the emergency, the entire country began a shift to the cloud. The rule of law was also adapted in line with this tendency. Fortunately for Ukraine, the Russian side was not prepared enough to execute attacks aimed at the cloud and APIs. So far, Russia has tried to inject malicious code that has not, however, achieved its intended goal, which means they have seen an urgent need to adapt to new technologies.\n\n## Lessons to be learned\n*Such is cyber warfare, as soldiers actually do it.* The key to the resilience of the government and the state is moving to the cloud. Not fully, of course, but if done rationally and with proper control this process seems inevitable.\n\n*Such is cyber-resilience in reality.* Attention needs to be paid not only to data and infrastructure, but also to critical infrastructures, since they are proving to be more resilient than originally thought.\n\n*Hacktivist groups exist – What will their future be?* Many civilian hacker groups support one side or the other, so the doubt rightly arises: what will their will be after the war? Even if the rest of the world stays out of the conflict, cybercrime groups trained in the war can mean a problem for them in the future.\n\n*A large amount of data has been put into the ‘wild’,* and will be used to nurture artificial intelligence in the coming years.\n\n*The convergence of space and cyber operations is clear,* with space warfare taking place through cyberspace.\n\n*Personal security will be critical in software development.* It is not enough to protect APIs like IT, one must also pay attention to the identity of the developer, given the fact that hundreds of thousands of Russian software developers have been left without work, and are expected to flood the industry.\n\n*Cyber warfare must also be taken into account in the corporate risk model.* If the war reaches a status quo and the two sides are no longer preoccupied with each other, revenge and retaliation are expected. This may seem like a rather ominous, negative-sounding prediction, but for software security, it is essential to know what solutions are available and which ones need to be improved.\n","date":"June 29, 2022","id":"Blogposts_26","short_description":"A new chapter in the security of our world opened on 24 February 2022. APIs are expected to be the most attacked interfaces in 2022.","isEnglish":true,"isHungarian":true,"slug":"csaba-krasznay-wars-and-cyber-warfare-in-the-age-of-ap-is","title":"Wars and Cyber Warfare in the Age of APIs"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/jefferson_santos_9_So_Cny_Qmkz_I_unsplash_v2_279d0b5a59.jpg"},"content":"Today, both our everyday experiences and objective data tell us that online fraud is one of the major cyberthreats we face. As [Europol’s Internet Organised Crime Threat Assessment (IOCTA) 2021](https://www.europol.europa.eu/cms/sites/default/files/documents/internet_organised_crime_threat_assessment_iocta_2021.pdf) writes, “Criminals continue making significant profits as well-known types of online fraud continue to be effective. While criminals have not had to re-invent their modi operandi, they continue to refine them, making them more targeted and technically advanced.” Let’s focus on the last two words as we examine the tools of online fraudsters. The first notable thing is that they are using automation. An authentic-looking website in several languages can be set up in minutes, and chatbots can be used for immediate response for even the most obvious frauds. Second, cybercriminals are successfully using digital communication services, like mass SMS sending, voice-over-IP with call numbers in any country, mimicking a call center, or simply sending spam emails through unprotected mail servers. Third, as social engineering is a key to success, they often use data from previous data breaches, such as email addresses or phone numbers. Fourth, they frequently hack or simply log in to an already existing online shop with fake accounts and upload products that will never be shipped after payment.\n\nAll of these tools assume a misconfigured web-based service of an innocent organization. Many automated website creation tools, chatbots, and digital communication services can be found legally as internet services. Meanwhile, unprotected personal data, weak mail servers, and vulnerable online shops can also be found on the internet, but their services are not intentional and cannot be used legally. Unfortunately, criminals don’t care about legal use. But worse, innocent organizations either don’t care or are unaware of these problems, even though with targeted countermeasures online fraudsters would be robbed of some of their major tools. The best method of prevention is API security with fraud detection.\n\nWe know that this is not obvious at first sight, so let us explain. Let’s assume you are a service provider offering digital communication, automated marketing, or payment services. As an agile company, you are offering your service via API for your customers. Have you ever gotten a request from the local police to provide digital evidence, like logs for an investigation related to one of your users? Or have you ever been notified by the local data protection authority that an investigation had been initiated under GDPR against you, as accounts from a huge data breach in your system had been used in cybercrime due to an OWASP Top 10-like problem? Perhaps, the national CSIRT warned your ISP that your IT infrastructure is part of a botnet, operated through an API vulnerability, and that you need to take action? If the answer is yes, do you feel that the frequency of police or agency requests is rising, and you need to spend more and more human resources on this task? If the answer is no, you are one of the lucky ones, but it is still worth bearing in mind that the [Federal Trade Commission’s data shows a more than 70% rise in frauds in 2021 over 2020](https://www.ftc.gov/news-events/news/press-releases/2022/02/new-data-shows-ftc-received-28-million-fraud-reports-consumers-2021-0), with online frauds in second place. In fact, we have no doubt that an affirmative answer is just a matter of time.\n\nLuckily, cybercriminals are lazy enough to often use the same tactics, techniques, and protocols for an extended period. If organizations can filter out already known fraudulent activities at API endpoints, they can keep away illegitimate users from their services and should spend less time evidence gathering for the police or simply protecting their digital services. While traditional cyber threat intelligence can provide indicators of compromise like IP addresses, file hashes, or DNS information, they are usually not able to detect fake or stolen accounts or newly created email addresses that have been used for a service subscription. With a more thorough analysis of API traffic, not just with a network-centric focus on already known malicious IPs, TOR exit nodes or suspicious VPNs, but with a content analysis on accounts, phone numbers, social media profiles, or even the traffic origin’s device fingerprinting, cybercriminals can be identified before they can start their operation. Which is why we can safely say that [fraud detection as an additional intelligence layer on API protection](https://balasys.eu/en/proxedo-api-lifecycle-platform/fraud-detection) is a must in the fight against cybercrime.\n\n\n\nPhoto by Jefferson Santos on Unsplash.","date":"June 24, 2022","id":"Blogposts_25","short_description":"According to Europol, online fraud is one of the major cyberthreats we face. One of the effective tools against them is a content analysis on API traffic.","isEnglish":true,"isHungarian":true,"slug":"api-security-and-online-fraud-what-is-the-connection","title":"API security and online fraud? What is the connection?"},{"author":"Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/Untitledddd_2af8fd640e.png"},"content":"![bs_fraud-ig_en_web03.png](https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/bs_fraud_ig_en_web03_d6cc376831.png)\n\n","date":"June 17, 2022","id":"Blogposts_24","short_description":"The infograph gives insight into the global trends concerning fraud and demonstrates why you need to implement fraud prevention measures.","isEnglish":true,"isHungarian":true,"slug":"fraud-infograph","title":"The growing costs of fraud "},{"author":"Szilárd Pfeiffer, Security Engineer & Evangelist, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/UNODC_2_cb8008b7f3.jpg"},"content":"The member states of the [United Nations](https://www.un.org/) are preparing to negotiate a draft of a new convention on cybercrime. [United Nations Office of Drugs and Crime](https://www.unodc.org/) have invited NGOs and other stakeholders to participate in the negotiating sessions and share their views and expertise in this field. Our colleague, Szilárd Pfeiffer, Security Engineer & Evangelist at Balasys, has shared his thoughts on data privacy, encryption, and cybercrime as a member of the [Cybersecurity Tech Accord](https://cybertechaccord.org/) with the delegates of the member states:\n\n> The first international milestone in the fight against cybercrime was the [Council of Europe](https://www.coe.int/)'s [Budapest Convention](https://en.wikipedia.org/wiki/Convention_on_Cybercrime). The Budapest Convention not only [defined](https://net.jogtar.hu/jogszabaly?docid=A0400079.TV) the concepts of cybercrime, but also contained procedural rules. To this day, the convention remains one of the starting points for international regulation of cybercrime. It may also serve as a good guideline for the regulation to be developed by the United Nations.\n>\n> However, all regulation can contain points of debate. In the case of the Budapest Convention, the issue of privacy is one such point. It has been the subject of criticism over the last two-decade history of the convention. The convention sets out obligations for collecting, recording, and intercepting content data in real-time, transmitted by computer systems. It is important to highlight that the [vast majority](https://transparencyreport.google.com/https/overview) of the content data that is transmitted through the internet is encrypted. This means that data can only be collected and recorded in encrypted form. To break the encryption, law enforcement agencies need a backdoor in the system or a deliberate weakening of the encryption. These are theoretically and technologically feasible, but they raise practical feasibility concerns, doubts concerning proportionality and security risks.\n>\n> Before continuing, I would like to emphasize that I do not intend to question the importance of fighting against cybercrime, but merely to find a way to minimize both security risks and privacy concerns.\n>\n> In order to deliberately weaken any encryption algorithms, the active involvement of all the major players in the technology sector is essential, as they should implement these weakened encryption algorithms in their commercial products. At the same time, we should not forget the [free software movement](https://en.wikipedia.org/wiki/Free_software_movement) alongside the big tech giants. In this community, efforts to weaken encryption may be resisted because of their strong commitment to both trusted technologies and privacy. It is important to emphasize that the encryption software products we currently use in most web, cloud, and mobile technologies on our smartphones and laptops have been developed by technology companies and members of the free software movement.\n>\n> Even if methods to weaken encryption can be successfully enforced, the question is what the drawbacks are alongside the benefits they bring. For law-abiding citizens, surveillance is likely to be 100% successful, but for criminals, this rate might not be significantly higher than it is now.\n>\n> For instance, free software is never backed by a single organization, company, or state, but by decentralized communities that no one directly governs. The essence of [free software](https://en.wikipedia.org/wiki/Free_software) is the right that users are [free to modify](https://en.wikipedia.org/wiki/The_Free_Software_Definition#The_Four_Essential_Freedoms_of_Free_Software) the functionalities according to their needs. This means that cybercriminals can also evade the surveillance and weakened encryption that law enforcement agencies are able to break. In other words, our tools against the most dangerous cybercriminals and terrorists will be no more effective than they are today.\nWhatever solution we choose, let us not forget that backdoors in our security systems can be exploited not only by us, but also by our enemies – against us. Cybercriminals today are still working hard to find specific software flaws that can be used to break into computer systems to acquire or corrupt as much data as possible. These criminals, knowing that there is a backdoor in every encrypted communication on the internet, would probably devote all their resources to finding and exploiting it. If even one of these criminal groups succeeds, the impact is currently unimaginable.","date":"June 13, 2022","id":"Blogposts_23","short_description":"United Nations is preparing to negotiate a draft of a new convention on cybercrime. Szilárd Pfeiffer has shared his thoughts on data privacy and encryption at an intersessional consultation of the United Nations Office on Drugs and Crime.","isEnglish":true,"isHungarian":true,"slug":"weakened-encryption-is-a-silver-bullet-not-just-for-law-enforcement-agencies-but-for-cybercriminals","title":"Weakened encryption is a silver bullet - not just for law enforcement agencies, but for cybercriminals"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/ehmitrich_Wc_G7_D_Oyr_So_M_unsplash_1_24d7db5430.jpg"},"content":"A new chapter in the security of our world began on 24 February 2022. And the term \"our world\" must also include cyberspace, as the Ukraine-Russia war has openly demonstrated our dependence on information systems and the vulnerability of this ecosystem. Although the war news has so far focused on classic armed conflict, more and more is being learned about the activities and tools of individual, state and non-state hacker groups. The Cybersecurity and Infrastructure Security Agency (CISA), for example, is constantly raising awareness of both newly discovered [codes attacking industrial systems](https://www.cisa.gov/uscert/ncas/alerts/aa22-057a) and well-known yet [routinely exploited vulnerabilities](https://www.cisa.gov/uscert/ncas/alerts/aa22-117a). Companies can be prepared for a renewed focus on cyber operations as the battle for physical space subsides, with potentially less emphasis on financial gain and more on destruction.\n\nAll this has occurred shortly after COVID led most companies to make a decade-long leap in digital transformation. Much of enterprise IT has moved to the cloud, and solutions that exchange data via APIs have become common. However, the rapid digital transition has by definition been driven by a focus on efficiency rather than cybersecurity. It is no coincidence that Gartner predicts that [APIs will be the most attacked interfaces in 2022](https://www.gartner.com/en/webinars/4002323/api-security-protect-your-apis-from-attacks-and-data-breaches).\n\nSo even in a disrupted global security environment, the predictions of experts suggest that Western companies and critical infrastructure operators could have months to prepare for increased cyberattacks. Of course, years of work cannot be completed in this timeframe, but significant results can be achieved in the short term by adopting Zero Trust planning principles. CISA's recommendation, for example, highlights the importance of network micro-segmentation, increased control of privileged users and detection of signs of unusual behavior, and an overall reduction in the attack surface. In practice, these tasks are challenging enough individually, but meeting the full CISA list is almost an impossible task for most companies, while the likelihood of experiencing a cyber attack is higher than ever.\n\nNew types of challenges therefore require new types of solutions. Of course, you can't jump years ahead in product development, but re-tuning, integrating and re-designing existing solutions to a Zero Trust approach can provide a quick and cost-effective way to strengthen your cybersecurity. This is why Balasys has come up with an innovation that can provide an effective solution to current challenges such as API interface management and security support, filtering of traffic from the web with web application firewall (WAF) and micro-segmentation of the network, and filtering of malicious traffic with a behavioral analysis. The solution is available as [Proxedo API Lifecycle Platform (PALP)](https://balasys.eu/en/proxedo-api-lifecycle-platform).\n","date":"June 1, 2022","id":"Blogposts_22","short_description":"A new chapter in the security of our world began on 24 February 2022. It's time to prepare your organization against an even stronger wave of cyberattacks.","isEnglish":true,"isHungarian":true,"slug":"new-security-tools-are-required-in-a-new-era","title":"New security tools are required in a new era "},{"author":"Horváth László, presales mérnök, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/clayton_cardinalli_hk_J_Nx0_E_Dbj_E_unsplash169_7002e6ffcd.jpg"},"content":"A zsarolóvírusok (ransomware-ek) továbbra is az egyik legsúlyosabb kiberfenyegetést jelentik a vállalatok és szervezetek számára világszerte. Legyen szó az egészségügyről, vagy az agrár-élelmiszeriparon át az elektronikai gyártásig, bármely ipari- vagy szolgáltatási ágazatról, megfelelő védelmi intézkedések nélkül senki és semmi sincs biztonságban. A fertőzések pusztító hatásúak lehetnek, a helyreállítás pedig nehéz és hosszadalmas folyamat.  \n\nHa egy zsarolóprogram bejut egy számítógépre vagy szerverre, titkosíthatja a tárolt adatokat vagy akár zárolhatja az operációs rendszert. Mindemellett fennáll az adatlopás kockázata is. Természetesen ez nem csak az irodai alkalmazottak számítógépeit érinti, a kiberbűnözők támadásukkal teljes szolgáltatásokat vagy gyártósorokat, vezérlőközpontokat tehetnek működésképtelenné.   \n\nAmint a zsarolóvírus „túszul ejti az adatokat”, váltságdíjat követel a hozzáférésért. A váltságdíj összege széles skálán mozog, és többnyire az áldozathoz igazodik, vagyis az adatok vélt értéke és a megtámadott cég pénzügyi helyzete alapján határozzák meg. A legutóbbi váltságdíj követelések elérték a 25 millió dollárt is. A hatóságok ugyanakkor nem bátorítják a károsultakat a váltságdíjak kifizetésére, hiszen a fizetés nem garantálja a fájlok visszaszerzését.  \n\nA helyzet súlyosságát jelzi, hogy az amerikai Nemzetbiztonsági Ügynökség (NSA), a Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökség (CISA), a Szövetségi Nyomozó Iroda (FBI), valamint az Egyesült Államok Titkosszolgálata (USSS) összefogva, közös [ajánlást](https://www.cisa.gov/uscert/sites/default/files/publications/AA21-265A-Conti_Ransomware_TLP_WHITE.pdf) tett közzé a létfontosságú iparágak számára, hogy segítsék a támadások megelőzését, valamint a károk enyhítését.   \n\nMíg 2021-ben összesen mintegy 400 vállalatot érintett világszerte a „Conti” kiberbűnözői csoporthoz köthető bejelentett ransomware támadások száma, addig 2022 év elejére ez a szám már elérte az 1000-es nagyságrendet, és folyamatosan növekszik. A legutóbbi áldozatok közül érdemes kiemelni a japán elektronikai gyártó óriást, a Panasonicot, amelyet idén februárban támadtak meg, illetve a Nordex európai szélturbina-gyártó óriáscéget, amit márciusban. De indítottak már támadásokat olajterminálok, gyógyszeripari vállalatok, élelmiszergyártók, IT-szolgáltatók és mások ellen is. Az áldozatok között olyanokat találhatunk, – a teljesség igénye nélkül, – mint Írország Nemzeti Egészségügyi Rendszere, vagy a SEA-invest, a világ egyik legnagyobb terminálüzemeltetője (25 kikötőben tevékenykedik két kontinensen), a CS Energy, Ausztrália legnagyobb áramszolgáltatója, vagy az iTCo új-zélandi illetőségű informatikai szolgálatatásokat nyújtó vállalat.   \n\nHa el akarja kerülni, hogy zárolt laptopok, szerverek vagy titkosított fájlok tömkelege előtt találja magát, fontos, hogy felkészült legyen. Miután számítógépes rendszereit már megtámadták, túl késő a megfelelő védelem kialakításához.\n\n## Hogyan épül fel a Conti zsarolóvírus támadása?\nA Conti-csoport tagjai többnyire személyre szabott, megtévesztő adathalász e-mail linkeken, vagy csatolmányokon keresztül jogosulatlan hozzáférést szereznek az áldozatok hálózataihoz, illetve lopott, vagy gyenge jelszóval védett távoli asztal hozzáférések (RDP - Remote Desktop Protocol) hitelesítő adatainak segítségével lépnek be a vállalati hálózat infrastruktúrájába.   \n\nA fentiek mellett a Conti fegyverként használja a Word dokumentumokba beágyazott PowerShell szkripteket,   a támadás kezdeti szakaszában, a célzott támadások végrehajtására tervezett Cobalt Strike távoli hozzáférési eszközt Word dokumentumokon keresztül állítják be.  \n\nAz API kommunikáció terjedésével könnyen célponttá válhatnak ugyanakkor az API hívások is, melyek rakományába (payload) ágyazott [XSS](https://www.cert.hu/cross-site-scripting-xss) vagy Injection típusú támadások segítségével szintén el lehet érni rosszindulatú kódok futtatását a megtámadott rendszereken.  \n\nEzt követően az [Emotet](https://nki.gov.hu/figyelmeztetesek/karos-kod/emotet-malware-leiras/) moduláris malware-t is elhelyezik a hálózaton, amit elsősorban más malware-változatok, például a TrickBot és az IcedID letöltésére használnak, így szerezve további hozzáféréseket a zsarolóvírus telepítéséhez.   \n\nA behatolók átlagosan négy nap és három hét közötti időtartamban figyelhetők meg az áldozat hálózatán belül, a zsarolóprogram telepítése előtt. Ezalatt elsősorban dinamikus link könyvtárakat (DLL) használnak a vírus terjesztéshez.   \n\nElőször a hálózaton már rendelkezésre álló eszközöket használják, majd szükség szerint olyan további eszközöket vonnak be, mint pl. a Windows Sysinternals és a Mimikatz, hogy növeljék a jogosultságokat, és oldalirányban mozogjanak a hálózaton, mielőtt kiszivárogtatják vagy titkosítják az adatokat. Miután a támadók telepítették a zsarolóvírust, továbbra is a hálózatban maradhatnak…\n\n## Hogyan védekezzünk?\nA fent említett ajánlás alapján a következő megelőző intézkedéseket tartjuk fontosnak: \n\n### Multifaktoros hitelesítés (MFA) megkövetelése\n- Alkalmazzunk multifaktoros hitelesítést a hálózati erőforrások távoli hozzáféréséhez.\n\n### A hálózat szegmentálásának megvalósítása és forgalmának szűrése\n- Az egyes hálózatok és funkciók közötti mikroszegmentáció megvalósítása és biztosítása elengedhetetlen a zsarolóvírus terjedésének csökkentése érdekében. Ezek kialakításakor kiváló támpontot jelent az amerikai Nemzeti Szabványügyi és Technológiai Intézet (NIST) Zero Trust témájú publikációja (NIST SP 800-207). Hozzon létre egy demilitarizált zónát, amely megakadályozza a szabályozatlan kommunikációt a hálózatok között. \n- Szűrje a hálózati forgalmat, ezzel is tiltva a be- és kilépő kommunikációt az ismert rosszindulatú IP-címek felé.\n- Használjon erős spamszűrőket, ezzel megakadályozva az adathalász e-mailek eljutását a végfelhasználókhoz. \n- Vezessen be egy felhasználói képzési programot, hogy a felhasználók felismerjék a rosszindulatú weboldalakat, illetve e-maileket és mellékleteiket. \n- Szűrje a futtatható fájlokat tartalmazó e-maileket, hogy azok ne jussanak el a végfelhasználókhoz.\n- Vezessen be URL-blokkoló és engedélyezési listákat annak megakadályozására, hogy a felhasználók elérjék a rosszindulatú weboldalakat.\n\n### Az operációs rendszerek és szoftverek naprakészen tartása\n- Állítsa be az antivírus/antimalware programokat úgy, hogy rendszeresen vizsgálják át a hálózati eszközöket naprakész szignatúrák használatával.\n- Frissítse rendszeres időközönként a hálózati eszközök operációs rendszereit, alkalmazásait és firmware-eit.\n- Fontolja meg egy központi patch kezelő szoftver használatának bevezetését.\n\n### Felesleges alkalmazások eltávolítása és rendszeres ellenőrzések végzése\n- Távolítson el minden olyan alkalmazást, amelyet a napi működéshez nem tart szükségesnek. A Conti támadók legális alkalmazásokat, például távfelügyeleti szoftvereket és távoli asztal hozzáférést biztosító eszközöket használnak fel a bejutásra.\n- Vizsgáljon meg minden engedély nélküli szoftvert, különösen a távoli asztal elérésre vagy távfelügyeletre használtakat.\n- Vezessen be alkalmazásengedélyezési listákat, amelyek csak az ismert, és a szervezet biztonsági házirendjében szereplő programok futtatását engedélyezik a vállalat rendszerein. Vezessen be szoftverkorlátozási házirendeket (SRP-ket), vagy más felügyeleti eszközöket, amelyek megakadályozzák, hogy a programok olyan helyekről fussanak, amelyek gyakran a zsarolóvírusok futtatásának kiindulópontjai: például a népszerű internetböngészőket, vagy a kitömörítést végző programokat támogató ideiglenes mappák. Itt jegyeznénk meg, hogy a megfelelő házirendek kialakítása szintén részét képezi a manapság méltán népszerű (feljebb már említett) Zero Trust szemléletnek.\n- Akadályozza meg a rosszindulatú kódok futtatását az e-mailen keresztül továbbított Microsoft Office fájlokban található makró szkriptek letiltásával. Fontolja meg az Office Viewer szoftver használatát az e-mailben továbbított Microsoft Office fájlok megnyitásakor a Microsoft Office csomag „teljes” alkalmazásai helyett.\n\n### Távoli hozzáférés korlátozása, különös tekintettel a távoli asztal hozzáférések (RDP) korlátozására\n- A kockázatok felmérése és mérlegelése után, ha az RDP-t operatív szempontból szükségesnek ítélik, korlátozza a kiinduló forrásokat, és írjon elő többfaktoros hitelesítést.\n\n### Felhasználói fiókok biztonságossá tétele\n- Rendszeresen ellenőrizze a privilegizált felhasználói fiókokat, és konfigurálja a hozzáférés-szabályozást a lehető legkisebb jogosultság (least privilege) és a feladatok szétválasztásának elve alapján.\n- Rendszeresen ellenőrizze a naplófájlokat annak érdekében, hogy a létrejött új fiókok valós és legitim felhasználókhoz köthető hozzáférések legyenek.\n\n## Összefoglalás\nA Conti vagy más zsarolóvírusok által okozott károk valódi fenyegetést jelentenek a teljes ipari és szolgáltatói szegmens számára. Előfordulhat, hogy a támadók, rosszindulatú szoftverek már bejutottak a hálózatunkba. Egy kiterjedt támadás elleni felkészülésnek sokrétűnek és következetesnek kell lennie, ma már nem elegendő csupán egy tűzfal a határvédelemre.   \n\nA fenti ajánlások alapján jól látható, hogy a védekezés a teljes informatikai infrastruktúrát érinti. Többfaktoros azonosítást kell alkalmaznunk legalább a kritikus hozzáférési pontokon. Górcső alá kell vennünk a felhasználók hozzáféréseinek kezelését, különös tekintettel a privilegizált (kiemelt jogosultságú) felhasználókra, melyben segítségünkre lehetnek az IAM (Identity and Access Management) és PAM (Privileged Access Management) megoldások.   \n\nA megfogalmazott védelmi ajánlások nagyobbik részén könnyen felismerhető, hogy azok részei egy tágabb értelemben vett szemléletnek, az ún. Zero Trust (ZT) koncepciónak. Éppen ezért folyamatosan dolgozni kell a ZT minél teljesebb körű megismerésén és bevezetésén,   mely során fontos szerepet kap többek között a mikroszegmentáció (ezzel is akadályozva a támadók laterális mozgását), valamint a központi menedzsment és házirendkezelés is. Mindezek mellett a vírusvédelem, a tartalomszűrés, valamint a hálózati forgalom protokoll és applikációs szintű folyamatos szűrése és monitorozása sem szorulhat háttérbe.  \n\nHa kérdése van a fentiekkel kapcsolatban, [forduljon hozzánk bizalommal](https://balasys.eu/hu/contact/)! \n\n\n\nPhoto by Clayton Cardinalli on Unsplash","date":"May 5, 2022","id":"Blogposts_20","short_description":"A zsarolóvírusok nemcsak a magánszemélyek, hanem a vállalatok számára is hatalmas fenyegetést jelentenek. Közülük is kiemelkednek azonban azok az ipari cégek, amelyeknél egy informatikai leállás akár a gyártást is ellehetetlenítheti.","isEnglish":false,"isHungarian":true,"slug":"ujra-tamadasba-lendueltek-a-zsarolovirusok-celkeresztben-az-ipar-es-a-szolgaltatasok","title":"Az ipar a zsarolóvírusok célkeresztjében"},{"author":"Szilárd Pfeiffer, Security Engineer & Evangelist, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/robynne_hu_H_Orh_Cn_Qsxn_Q_unsplash_2_2048x1151_c970214143.jpg"},"content":"## The internet: where everybody is your neighbor\n\nThe internet is not as big as you might think. Until [IPv6](https://en.wikipedia.org/wiki/IPv6) arrives, there are fewer than 4 billion [IPv4](https://en.wikipedia.org/wiki/IPv4) addresses. In theory, it would be almost 4.3 billion addresses, but 600 million IPv4 addresses are [reserved](https://en.wikipedia.org/wiki/Reserved_IP_addresses). In practice, there are approximately 3.7 billion public and routable IPv4 addresses. Finding vulnerable machines among this crowd of IP addresses might seem like looking for a needle in a haystack, but this is not true. With automated tools, anybody can systematically scan the internet for various vulnerabilities in public services.\n\nThis kind of mass scan requires fewer resources than you might think. Assuming that checking for a vulnerability takes a maximum of one second, in one month hackers need to check around 1,400 machines a second on average to find every single device on the internet that is exploitable for a particular vulnerability. If the available period is just a week or a day, you need to scan around 6,000 or 43,000 services a second, respectively. Sounds like relatively high numbers, but if you consider that even a huge country like [China uses](https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation) less than 8% and [Russia uses](https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation) less than 1% of the available IP addresses, you can see that focusing on smaller targets decreases the required resources to a tenth or a hundredth.\n\nThe numbers above demonstrate that it is theoretically possible to mass scan the entire internet. Effective free-to-use tools can be used to perform mass scans, converting this academic opportunity into practice. [ZMap](https://zmap.io/), [Masscan](https://github.com/robertdavidgraham/masscan), and others promise to scan the entire public IPv4 address space in [some ten](https://github.com/zmap/zmap#zmap-the-internet-scanner) minutes or so on a typical desktop computer with a gigabit Ethernet connection. [Researchers proved](https://zmap.io/paper.pdf) that the time needed to perform application-layer scans in some cases could be [further reduced](https://jhalderm.com/pub/papers/scanning-sec14.pdf), meaning that mass scans will be able to discover any accidentally or willingly published application layer services in a short space of time.\n\n## Search engines for potential weaknesses\n\nHackers do not even have to perform mass scans themselves, as commercial services sell bulk data from their mass scans. It would still be challenging to inspect, cleanse, transform, and model the bulk data to discover necessary information, though companies such as [Shodan](https://www.shodan.io/) or [ZoomEye](https://www.zoomeye.org/) have already done the data analysis task for you. They also provide search engines to access their well-structured databases, which contain near real-time information about exploitable services worldwide. These databases can only be accessed for free with substantial limitations, but of course, you can pay a [subscription](https://account.shodan.io/billing) fee to reduce these limitations. The entry-level subscription cost is just a few dollars per month, meaning that the information price for the exploitable services is not high. Together with the numerous free-of-charge tools, this creates dramatically low barriers to entry for self-appointed hackers.\n\nSome can put the mentioned tools and services together and create a well-automated system, especially since [they provide](https://developer.shodan.io/)[APIs](https://en.wikipedia.org/wiki/API) to access their database. As you can see, you do not have to be a nation-state actor to perform effective scans for vulnerable services on the internet. Criminal and [hacktivist](https://en.wikipedia.org/wiki/Hacktivism) groups can also do it by using the mentioned services or creating and managing their systems – this is common practice. However, the situation is actually worse than that, as even a [script kiddie](https://en.wikipedia.org/wiki/Script_kiddie) could also find vulnerable services in their interest. The aforementioned search engines make it possible to filter the services by protocol, vendor, vulnerability, geolocation, etc. Someone with a low level of preparedness could cause harm to an organization by identifying targets with the mentioned tools using proof-of-concept implementations of the vulnerabilities. This can be true even if the author of the proof-of-concept implementation [discloses it responsibly](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure).\n\n## Operation technology is also under attack\n\nCyberattacks may use devices that are not strictly part of the IT infrastructure to achieve their goals. For instance, with Shodan, you can easily find webcams without any authentication or default username and password near or inside a targeted organization. A hacker can use unauthorized access to a webcam to observe the targeted site and create plans to circumvent the guards. Some hacking techniques depend on getting devices into the targeted organization or near it. For instance, installing an open Wi-Fi hotspot near the targeted network may cause devices of the targeted network to connect automatically to the malicious Wi-Fi hotspot. If this happens, a hacker can eavesdrop on any unencrypted traffic sent or received by the connected device to get usernames and passwords. Even if the data is encrypted, metadata can still be collected, such as the domain name of the visited sites. It also opens the possibility of an intrusion attempt that exploits vulnerabilities on the connected device. An open webcam increases the risk that someone might install a malicious device unnoticed, even if it is a guarded factory site far from overcrowded districts.\n\nSome people might think that no part of the critical infrastructures or [Industrial Control Systems](https://en.wikipedia.org/wiki/Industrial_control_system) (ICS) are ever connected directly to the internet without robust authentication. The reality is different. For instance, a necessary Shodan query result contains thousands of [Schneider Electric](https://en.wikipedia.org/wiki/Schneider_Electric) devices, mainly from Spain, France, and the United States. The manufacturer provides digital solutions for the energy and automation sector. You can also find thousands of devices by searching for network protocols (e.g., [Modbus](https://en.wikipedia.org/wiki/Modbus), [DNP](https://en.wikipedia.org/wiki/DNP3), [Fieldbus](https://en.wikipedia.org/wiki/Fieldbus), [PROFINET](https://en.wikipedia.org/wiki/Profinet)) used in [SCADA](https://en.wikipedia.org/wiki/SCADA) or Industrial Control Systems. It is possible that published [programmable logic controllers](https://en.wikipedia.org/wiki/Programmable_logic_controller) (PLC) do not lead to the most severe risk, as you can also find [human-machine interfaces](https://en.wikipedia.org/wiki/SCADA#Human-machine_interface) (HMI) published on the internet. These devices are usually accessible by the [Remote Desktop Protocol](https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) (RDP) servers, which can have both configuration and implementation issues. For instance, they may use NTLM authentication that has weaknesses and vulnerabilities.\n\n## Zero Trust to the rescue\n\nUnder such circumstances, neither industry nor other areas should assume that cyberattacks still don't target them. Today, an organization does not have to be targeted by attackers directly. Automated tools systematically search the internet for vulnerable public services and attempt to exploit them immediately. If they are successful, the tools begin a lateral movement to spread themselves through the organization as extensively as possible and wait for the attackers' commands. At that point, we have already lost. The best advice to prevent such a situation is what the [Zero Trust Security Model](https://en.wikipedia.org/wiki/Zero_trust_security_model) has been advising for decades and is now also followed by US governmental offices in line with President [Biden's executive order:](https://www.forrester.com/blogs/biden-executive-order-bets-big-on-zero-trust-for-future-of-us-cybersecurity/)\n\n1. Handle everything equally as a resource, independently of whether it is part of information technology (IT) or operational technology (OT), as both have the same importance.\n2. Allow access to resources only after strict authentication independently from the resource accessible from the internet, as an intranet service can still be a target of an insider attack or malicious software brought to the intranet by a personal device ([BYOD](https://en.wikipedia.org/wiki/Bring_your_own_device)).\n3. Prohibit plain text communication and use only encrypted connections with robust encryption algorithms to avoid the first step of each attack, eavesdropping.\n4. Apply the [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege) during the authorization to minimize the risk that an infected device might cause on your network, as it is able to access everything that the device user is permitted to access.\n5. Apply these controls in a session-based manner to minimize the period between the revocation and the enforcement of an authorization level revocation.\n6. [Continuously monitor](https://en.wikipedia.org/wiki/Continuous_monitoring) your devices and network to prevent or notify of any suspicious behavior.\n\n\n\nPhoto by Robynne Hu on Unsplash","date":"April 28, 2022","id":"Blogposts_21","short_description":"Think the internet is large enough to hide from criminals in the hope you won’t be the next victim of a cyber attack? Sadly, this is no longer the case. The internet is a global village, where everyone is your neighbor, and anyone can detect your mistakes and vulnerabilities. ","isEnglish":true,"isHungarian":true,"slug":"the-internet-is-a-global-village-not-a-metropolis","title":"The internet is a global village, not a metropolis "},{"author":"Romics Attila, Head of Service Delivery","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/romeo_varga_9_V_Mp_MZPJK_3k_unsplash_v3_a34d35030f.png"},"content":"Az elmúlt években az informatikai infrastruktúrákat ért incidensek száma folyamatosan emelkedett, miközben a kibertámadások egyre szofisztikáltabb módszerekkel érték el a céljaikat. Idén az amúgy is kedvezőtlen trend még tovább romlott az utóbbi hónapok geopolitikai történései, az orosz-ukrán háború, valamint a világszerte megfigyelhető, növekvő feszültség következtében. A támadások szektortól függetlenül szedik áldozataikat, melyek listáján jelentős szervezetek, vállalatok is szerepelnek. Elég, ha csak a Lapsus$ hackercsoport elmúlt hónapokban végrehajtott támadásaira gondolunk, amelyek során olyan neves vállalatokat értek komoly csapások, mint például az NVIDIA, a Samsung, a Vodafone, az Ubisoft vagy a Microsoft. \n\nAhhoz, hogy az incidensek hatékony megelőzéséről és a védelmi erőforrások optimális allokálásáról beszélhessünk, először célszerű röviden áttekinteni, hogy miként épül fel egy incidensreagálási folyamat. \n\n**Az incidensek életciklusa**\n\nAmikor egy nemkívánatos biztonsági esemény bekövetkezik, és sikerül azt detektálni, akkor veszi kezdetét az incidensreagálási folyamat első fázisa. Ez egy nagyon intenzív időszak az IT és a biztonsági csoportok számára, de nem kis terhet ró például a menedzsmentre és a kommunikációs szakemberekre is (az incidens nagyságától, kiterjedtségétől és az adatbiztonságra, illetve az üzleti folyamatokra gyakorolt hatásától függően). Az első napokban, esetleg hetekben a „tűzoltásé” a főszerep, amelynek során gyors (rövid távú) döntésekkel kell meggátolni a további károk bekövetkezését, és olyan intézkedéseket kell hozni, amelyek az üzletileg kritikus folyamatok mielőbbi helyreállítását elősegítik. Ügyelni kell arra is, hogy eközben a computer forensic elvei ne sérüljenek, és a digitális bizonyítékok (például a naplóállományok) biztonságba kerüljenek. \n\nAz incidensreagálás második szakasza hetekig is elhúzódhat, amelynek során már nem kizárólag az informatikai és üzleti folyamatok helyreállítása a cél, hanem azok átalakítása is szóba kerülhet a történtek figyelembevételével. Eközben gondoskodni kell a védelmi rendszerek megerősítéséről, és nem utolsósorban fontos szerep hárul a hatóságokkal, forensic szakértőkkel történő együttműködésre is. \n\nVégül az incidensreagálásnak egy hosszabb időszakot átölelő fázisa is van, amely legalább olyan fontos és erőforrásigényes, mint az előző szakaszok voltak. Ekkor kell ugyanis kezelni a támadás következtében bekövetkező, hosszú távon jelentkező negatív hatásokat. Ezek közül az egyik legfontosabb és legnehezebb a hírnéven esett csorba kiküszöbölése, de ugyancsak ekkor kell megvalósítani a megreformált védelmi stratégiát technológiai, szervezeti és humán szinten is. \n \n**Vélt károk - valós károk**\n\nA Deloitte által készített, „Beneath the surface of a cyberattack” című tanulmány abból az aspektusból vizsgálta a biztonsági incidenseket, hogy azok milyen mértékű károkat eredményeznek. Arra is rávilágított, hogy a kibertámadások gyakorta jóval nagyobb összegű kiadásokkal járnak, mint azt a szervezetek gondolják. Ennek oka, hogy a vállalatok, intézmények sokszor csak a közvetlen károkkal számolnak, holott ezek csak a jéghegy csúcsát jelentik. Általában azon kiadások kerülnek előtérbe, amelyek egy biztonsági incidens után fedezik az adathelyreállítást, az ügyfélértesítéseket, a kártalanításokat, a compliance feladatokat, az esetleges büntetéseket és nem mellékesen a védelmi rendszer megerősítésének költségeit. \n\nA felszín alatt azonban további pénzügyi erőforrásokat felemésztő károk is felmerülnek. Ilyenek például a vevők bizalmának elvesztése, a szerződéses kötelezettségek nem megfelelő teljesítése (támadás miatti késések, kötbérek), az üzleti folyamatokra gyakorolt negatív hatások, a kiberbiztosítási díjak emelkedése és nem utolsósorban a szellemi tulajdont képző javak esetleges elvesztéséből származó, hosszú távú hátrányok.\n\nEgy-egy biztonsági incidens pénzügyi hatásának pontos felmérése tehát korántsem egyszerű feladat, már csak azért sem, mert vannak olyan összetevői a „képletnek”, amelyek nehezen számszerűsíthetők. Tipikusan ilyen a hírnéven esett csorba, amelyet gyakorta csak közvetett módon (például az értékesítés visszaeséséből) lehet megbecsülni. \n\n**Zero trust, avagy elfogyott a bizalom**\n\nA napjainkban végrehajtott kibertámadások során alkalmazott módszerek és a célkeresztbe állított támadási felületek figyelembevételével már nem lehet hatékony védelmet kiépíteni a hagyományos biztonsági megközelítésekkel. Ennél ma már jóval több mindenről kell gondoskodni. Fel kell mérni, hogy milyen fenyegetettségekkel szemben kell védekezni, és azt, hogy pontosan mit is kell megóvni (eszközök, adatok, üzleti folyamatok stb.). Kockázatfelmérést követően lehet kijelölni a védelmi feladatokat, meghozni a szükséges intézkedéseket és nem utolsósorban allokálni az erőforrásokat.\n\nMára eljutottunk odáig, hogy abból az igencsak aggasztó helyzetből célszerű kiindulni, hogy a támadók, kártékony programok már bejutottak a hálózatunkba. Vagyis, hogy a határvédelem elesett, és további kontrollokkal kell megakadályozni a károkozásokat. Ennek alapjául a zero trust szolgál. \n\nA zero trust egy olyan kiberbiztonsági paradigma, amely a védelem fókuszát a statikus hálózati határvédelemről a felhasználókra és az IT-erőforrásokra helyezi át. Arra az alapelvre épül, hogy a bizalmat sohasem implicit módon adjuk meg, hanem folyamatos ellenőrzésekre van szükség. A nulla bizalom elvére épülő megközelítés szükségessé teszi a rendszerszintű tervezést, fejlesztést, implementálást. Kiemelt jelentőséggel bír az azonosságkezelés (Identity Management), ami a teljes szervezetet lefedi kezdve az Active Directory integrációtól, a kiterjesztett szerepkör- és hozzáféréskezelésen át, egészen a harmadik felektől származó alkalmazások és szolgáltatások támogatásáig bezárólag. Nemzetközi tapasztalatok és ajánlások szerint nem lehet figyelmen kívül hagyni a mikroszegmentálásra épülő megközelítéseket sem, amikhez központi menedzsment és házirendkezelés társul. Amennyiben ugyanis sikerül jól felügyelhető, kontrollálható szegmensekre osztani a hálózatot, akkor a támadók hálózaton belüli (laterális) mozgásának sokkal hatékonyabban lehet gátat szabni. \n\nTermészetesen a kellő szintű biztonság kialakításához és fenntartásához a technológiai védelem sem szorulhat háttérbe, így például a vírusvédelem, a tartalomszűrés, a hálózati szintű autorizáció, az adattitkosítás, illetve a VPN-támogatás sem. Mindezek mellett elengedhetetlen a folyamatos naplózás és monitorozás annak érdekében, hogy a nemkívánatos hálózati események, valamint anomáliák minél előbb kiszűrhetővé váljanak akár automatizált, gépi tanulásra épülő eljárásokkal. \n\nAmennyiben egy jól kialakított zero trust stratégia mentén sikerül megvalósítani az informatikai infrastruktúra átfogó védelmét, akkor az minden másnál jelentősebb kockázatcsökkentést eredményez a teljes szervezet számára. Nem kizárólag a jelen fenyegetettségeivel szembeni ellenállóképességet növeli meg, hanem kiváló alapot teremt a jövőben felmerülő kockázati tényezők kezeléséhez, valamint az újabb és újabb támadási felületek számának csökkentéséhez. Ennek köszönhetően jelentősen hozzájárul az előzőekben ismertetett, közvetett és közvetlen károk bekövetkezésének megelőzéséhez.\n\n\n","date":"April 14, 2022","id":"Blogposts_18","short_description":"A biztonsági incidensek által okozott károkat sok szervezet lebecsüli, ami gyakran negatívan hat a megelőző és a reagáló védelmi intézkedések hatékonyságára. ","isEnglish":false,"isHungarian":true,"slug":"megregulazott-incidenskezeles","title":"Megregulázott incidenskezelés"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/possessed_photography_E1_PQXK_Uk_Mw_unsplash_dadff99a61.jpg"},"content":"**Lessons learned from 2021 cyberattacks**  \n2021 had some infamous cyberattacks, such as SolarWinds, Colonial Pipeline, JBS, Kaseya, and Pegasus, and the emergence of some nasty vulnerabilities, like Microsoft Exchange Server and Log4J. Was it a bad year or not from a cybersecurity perspective? Were there any novelties, or was it just business as usual? The answer is not so simple. It is certainly unusual for an Executive Order from the President of the United States to deal with technical details of IT security (namely Zero Trust), but at the end of January 2022, two memorandums (Memorandum on Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems and MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES - Moving the U.S. Government Toward Zero Trust Cybersecurity Principles) reminded us of the imbalance of the capabilities of attackers and the challengers for defenders. Yet neither ransomware nor 0-day vulnerabilities show us something new. In this article, we try to outline the most important lessons we’ve learned in 2021.\n\n**Cybercrime gangs began acting as APT groups:** The connection between secret services and organized crime is always a grey zone, but also part of their daily business. We can assume this relation is true in cyberspace too. However, in the most serious ransomware attacks, it seems that cybercriminals used detailed operation planning, high-quality open-source intelligence, and multiple attack vectors. We don’t know yet whether they just learned from the bests or hired some ex-officers who supported the operations, but in the past, groups like REvil were not as prepared as they were in 2021.\n\n**Sin deserves its worthy punishment:** Apropos of REvil. They were arrested in January and the infrastructure was ’neutralized’. In Russia. Which is quite unusual. But there were other interesting cases in the last year in Ukraine, Hungary, and Romania, to name but a few. It seems that the US-European law enforcement cooperation is working well, and if they get the right political support, even Russia is willing to do something to combat the significant rise in cybercrime.\n\n**Temporary silence in state-sponsored attacks:** Okay, we started 2021 with SolarWinds, attributed to Russia, and large-scale attack against Microsoft Exchange Servers, attributed to China and even Germany accused Russia with interference with their election, using the EU Cyber Diplomacy Toolbox, but we were really missing something… BIG. As the tension around Ukraine emerges, we can assume that countries are keeping their powder dry and don’t want to expose their real capabilities. In a real military situation, the element of surprise is important, and the same is true in cyberspace. As both Ukraine and Belarus were hit in January, we can predict that 2022 will be get a whole lot hotter in this sphere.\n\n**0-day vulnerabilities are gems:** Both SolarWinds Orion backdoor and Exchange vulnerabilities were first exploited by countries and discovered later by independent researchers. Log4J could have happened in the same way, as it was discovered by a Chinese security expert, and according to Chinese law, such discoveries should be reported to the state first. Alibaba Cloud, the employer of the researcher, of its failure to report. NSO Group used several 0-days in their Pegasus spyware tool, with the Israeli government’s knowledge. We can be sure that governments are stockpiling valuable software bugs to use in conflicts.\n\n**Supply chain attacks as real threats:** A DDoS against our DNS provider? A targeted attack against a software developer to build a backdoor into the product running deep inside our network? Or just an unintentional network configuration that stops Facebook working? All of these incidents are happening outside the organization, but as a collateral victim, the organization’s operation will also be affected. Supply chain-related risks were never as real as in 2021. Meanwhile, cloud outages are coming.\n\n**Silent building on the defenders’ side:** Financial institutions and huge governmental systems were not really hacked in 2021. There are no new disruptive technologies on the product horizon of cybersecurity. Everything is calm on the market. If 2020 was the year of rapid digital transformation, 2021 was the year of cleaning up the ensuing mess in terms of security. There are a lot of great products on the market, and even vulnerable APIs can be protected, but traditional security solutions should be combined with the latest technology, something that requires significant time and resources. Zero Trust seems to be the directive principle that can provide us with more secure cyberspace in the near future.\n\n\nPhoto by <a href=\"https://unsplash.com/@possessedphotography?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Possessed Photography</a> on <a href=\"https://unsplash.com/s/photos/attack?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash</a>\n  ","date":"March 16, 2022","id":"Blogposts_19","short_description":"What are the key learning points of 2021 from a cybersecurity point of view? Csaba Krasznay, Director of Cybersecurity Research Institute at National University of Public Service shares his thoughts.","isEnglish":true,"isHungarian":true,"slug":"lessons-learned-from-2021-cyberattacks","title":"Lessons learned from 2021 cyberattacks"},{"author":"Szilárd Pfeiffer","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/zt_blog_header01_8e70beda54.jpg"},"content":"**There is a seemingly trivial solution to any remote code execution attacks, namely: not to let the inbound traffic match the pattern that triggers the vulnerability of the server. Easy to say, but hard to do. There are[ almost endless variations](https://hackertarget.com/detection-of-log4j-vulnerability/) of traffic patterns that could trigger the[ critical severity Log4j vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2021-44228). As a result, malicious patterns of inbound traffic are extremely hard to detect. At the same time, outbound traffic caused by a Log4Shell attack site is easily detectable. Because this kind of traffic is always considered suspicious, as it targets random internet sites with a special protocol, according to the Zero Trust model it should not be allowed.** \n\nOutbound traffic to a random internet site is a peculiarity of Log4Shell attacks that other arbitrary code execution attacks do not necessarily have. This peculiarity should help the prevention of exploitation not only when network defense is based on the perimeter-less Zero Trust Network Architecture security model but also if it is a perimeter-based castle-and-moat defense. The consequence of a Log4Shell attack is that the exploited server tries to download code from a random internet site owned by the attacker. If the download is successful, the server runs the code, usually to grant a backdoor to the attacker. Some questions arise. How could the access of random internet sites be successful? And even if it succeeded, how was the attacker able to access the opened backdoor? \n\n\n## Zero Trust renders Log4Shell harmless \n\nUnlike Zero Trust, which requires micro segmentation, traditionally demilitarized zones (DMZ) are the best practice to isolate external-facing servers of the organization from both the local area network (LAN) and larger, usually untrusted networks such as the internet. Access to services running on the servers of DMZ, except public services such as web services, should be forbidden or strictly authenticated from the direction of the internet. As there are only a few legitimate reasons why a server in a DMZ would want to access the internet, this kind of traffic should also be strictly controlled. **Even if a Log4Shell vulnerability is exploited in the server, it cannot download and later run any malicious code, as the outgoing traffic from the DMZ to the internet would have been prohibited.** A strictly defended DMZ could prevent a Log4Shell attack, as exploited servers mostly use protocols ([LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol),[ JNDI](https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface)) to download the malicious codes, but it is hard to imagine legitimate reasons to permit the use of these protocols to access anything, or at least a random site on the internet, especially from a DMZ. \n\nZero Trust specifies and generalizes the methods and approaches already applied in any DMZ. Zero Trust requires the least privilege principle, for instance. Servers could access only the strictly necessary resources – e.g., an update server – on the internet with a specific address, port, and protocol. This way of working does not lead to serious administrative costs for the security team, as there are only a few reasons why a server needs to access the internet, and the firewall rules created as a result of these reasons are rarely changed. If for whatever reason, access to trusted resources cannot be tightened, protocol enforcement and content filtering become priorities. The least privilege also means that a resource can only be accessed with the necessary protocol. Even if an attacker runs a server on a port that is assumed to be allowed from a DMZ, such as HTTP(S), downloading the malicious code will fail when Log4j uses another protocol (LDAP, JNDI) than the expected one (HTTPS). Even if the necessary protocol is used, content filtering can detect malicious codes. \n\n\n## Zero Trust defends against RCE attacks \n\nA remote code execution (RCE) attack does not necessarily require an external server on the internet from where the malicious code is acquired. In these cases, the code is injected into a legitimate but malformed request that exploits the vulnerability. It is almost impossible to detect a pattern that exploits a zero-day vulnerability, so we should focus on the consequences of running an arbitrary code on the exploited server. If the goal is simply to bring the service down immediately after exploitation, the attacker will succeed, as there are several ways to do so only on the privilege level of the exploited service. However, privilege escalation very frequently follows an RCE, which means that a suitable patch management process is essential to minimize this threat. \n\nIt is likely that one of the next steps will be[ lateral movement](https://en.wikipedia.org/wiki/Network_Lateral_Movement), i.e., trying to infect other servers of the organization. This requires the conversion of the exploited server to a command-and-control (C&C) machine that requires permanent access. If we follow the principles of Zero Trust, only the public service of a server in the DMZ can be accessed from the internet. Accessing any other services on the server is usually either not permitted or only after strong authentication. If this is indeed the case, the C&C server cannot be accessed by the attacker. Even if the public service itself can be used to control the server, **eavesdropping and lateral movement cannot be performed if the server is isolated by micro segmentation in line with Zero Trust principles**. Data leakage is still a serious threat if the attack is targeted and the exploited service can be used to leak data, but by applying Zero Trust principles this issue can be localized. \n\n\n## Think global, not local: One-by-one solution is ineffective \n\nLog4j developers have implemented a built-in solution to control the outgoing LDAP and JNDI connections. This could be a solution for those affected by these attacks in the short term, but it cannot save time in the long term, as a large amount of\tsoftware have or will have similar issues even if we do not know it today. These kinds of security issues are the result of the way the software industry now works. The rapid development cycles, the release pressure, the missing security mindset, the low[ test coverage](https://en.wikipedia.org/wiki/Code_coverage), the lack of[ security testing](https://en.wikipedia.org/wiki/Security_testing), among others, can all be the cause of security issues. Security experts, such as penetration testers, hackers, and crackers, think differently than developers. Developers mostly focus on the[ happy paths](https://en.wikipedia.org/wiki/Happy_path), whereas security experts focus on[ edge](https://en.wikipedia.org/wiki/Edge_case) and[ corner cases](https://en.wikipedia.org/wiki/Corner_case) and how to exploit them. However, the goals of a penetration tester and a cracker are entirely different. \n\nThough controlling outgoing connections from a server generally is a good idea, implementing it separately in all applications is presumably neither the most effective nor the fastest way. Different implementations of functionality like this may have other issues that increase complexity, especially if the goal is a comprehensive solution. Even if the developers of various software projects implement similar controls, it would require significant work. Maintainers then need to update a huge amount of software, which is a risk, and simply not possible in many cases, especially in the case of large organizations and IT infrastructures. According to Zero Trust Network Architecture, there should be a Policy Enforcement Point (PEP), which is responsible for enabling or terminating connections between a subject and an enterprise resource. Using a PEP, any outgoing connection from DMZ to the internet can be controlled carefully if they are not disabled. \n\n\n## Always strictly control your resources \n\nThe solution, at least until an era of security by design arrives, is to strictly control resources, where everything is considered as a resource, even if it is on the internet. **To avoid the consequences of vulnerabilities such as Log4Shell, we must control how resources can be accessed,** how they can access other resources, and how these access rules can be enforced on the network **using the least privilege principle and other principles of Zero Trust.** \n","date":"February 10, 2022","id":"Blogposts_16","short_description":"Log4Shell has made waves in the not-so stagnant waters of the IT Security industry last December. The post explains how organizations should apply Zero Trust to prevent Log4Shell - and similar - attacks.","isEnglish":true,"isHungarian":true,"slug":"how-would-zero-trust-prevent-a-log4-shell-attack","title":"How would Zero Trust prevent a Log4Shell attack?"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/cataclysm_7cfeee181e.jpg"},"content":"## 1.\tIncreasing cybercrime, notable arrests\nOkay, we admit it – this prediction is obvious. We can expect ransomware-as-a-service, ransom DDoS, affiliate programs of serious cyber-gangs. What will be unique is the regional spread of such devastating attacks. In the last year, ransom-like attacks have mainly focused on large and visible companies, but as affiliate programs open the show for local criminals, highly targeted attacks will also appear in smaller countries. Meanwhile, we can expect the first results of the law enforcement cooperation initiated by the United States in mid-2021 and the arrests of previously untouchable criminals.\n\n## 2.\tAn unforeseen twist in USA-China relations \nThere is huge tension between the two superpowers, including in cyberspace. At the beginning of 2021, a large-scale attack against Microsoft Exchange servers was attributed to China, although such operations had not really been conducted by the Asian country before. In President Biden’s second year, USA may also do something spectacular, in line with its defense forwards principle. We expect a strategic cyber-maneuver from one of the countries that will be visible to the public and uncover a surprising new feature in their armory.\n\n## 3.\tWhen SCA and cyber resilience meet…  \nSolarwinds case was a supply chain attack. Colonial Pipeline was a cyber resilience issue, due to a ransomware attack. What would happen if these two things meet? We assume that the log4j vulnerability is a warning sign for everyone and it is now clear that global IT is similar to the game Jenga: it doesn’t have a solid base; it is built on mud. We expect targeted attacks exploiting third-party software vulnerabilities in the supply chain, with financial intentions, against critical infrastructures that will result in unintentional service outages on a national or regional level.\n\n## 4.\tMore pressure in terms of compliance  \n2022 will be the year of EU cyber legislation. An NIS2 Directive aiming to increase the cybersecurity level of critical information infrastructure, DORA to extend cyber resilience of financial institutions, and a CER Directive to enhance critical infrastructure protection are all on the table, among other things. We expect a loud debate on these legislative actions in the second half of the year, similar to GDPR in 2018. The good news for security teams is that more compliance might mean larger budgets for security operations.\n\n## 5.\tFake news, fake news, everywhere  \nAs the tension rises in Western-Eastern relations (all eyes on the East-Ukraine border, the French presidential and US midterm elections), we expect to see more advanced information operation techniques. Our prediction highlights the extended use of deep fake and AI supported automation in the social media by rogue actors. In particular, governments of European Union countries should prepare for such attacks.\n\n## 6.\tSpread of managed security services and cloud security  \nManaged Security Services, cloud security and CISO-as-a-Service are nothing new. Why do we mention this area in our outlook? Because what is common in the most advanced countries is not necessarily as common in the rest of the world. Due to the changing threat landscape, extending compliance requirements and the lack of skilled cybersecurity workforce, more and more local companies should outsource their security operations. We predict a huge leap in this business segment, especially in smaller European countries.\n\n## 7.\tAdvent of Zero Trust  \nIt’s time to rethink our security architecture, because of the changing nature of cyberattacks or simply because of compliance requirements. Zero Trust Principle is a good candidate (and quite a strong compliance issue in the United States) for that change. We assume that for most organizations, this won’t entail too much more work, just engineering tasks, but we can predict the emergence of some great new technologies that can support this transition. Balasys has [some hints for you](https://balasys.hu/en/solutions/zero-trust).","date":"February 4, 2022","id":"Blogposts_17","short_description":"A lot of bad cyber-related things happened in 2021. Solarwinds, the Colonial Pipeline, and the Microsoft Exchange and log4j vulnerabilities, to name but a few. But what does the future hold for us in 2022? ","isEnglish":true,"isHungarian":true,"slug":"2022-year-of-the-cyber-cataclysm","title":"2022: Year of the cyber cataclysm?"},{"author":"Szilárd Pfeiffer, Security Evangelist & Engineer, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/zt_blog_header01_07020d606e.jpg"},"content":"**Though we would not argue against the importance of detecting malware, there should also be a cheap and effective step before detection, namely prevention. A malicious email that is never delivered to the recipients will never cause security issues. [According to CSO](https://www.csoonline.com/article/3153707/top-cybersecurity-facts-figures-and-statistics.html), 94% of malware in 2020 was spread through the email system.  Email, which remains an essential tool and still forms the basis of many business processes, uses one of the oldest and least secure communication protocols on the internet. Even though there are several ways to apply security policies on the mail transfer protocol to prevent the delivery of suspicious mail, these methods are not nearly as widely declared and enforced as they should be.**\n\nThe security of the other commonplace, older protocol, HTTP, the basis for the World Wide Web, has been in focus for more than ten years, leading to significant progress in this area. It is enough to mention the fact that HTTP has been almost completely replaced by HTTPS, an encrypted version of the same protocol that provides confidentiality, integrity and authenticity during data transfer. It should not be forgotten that just a few years ago, several sites sent credentials, customer data, or payment information on the internet without any kind of encryption. Post CCPA, GDPR, and other similar regulations, this is now almost unimaginable. A simple news site without any kind of authentication now uses HTTPS, quite rightly to avoid modification of content during transfer, just for instance. Try to imagine the potential consequences of a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) on one of the most popular news sites. As many business processes use the web and the protocol itself could not be improved, the ecosystem as a whole had to be improved to prevent downgrade attacks, clickjacking, cross-site scripting, and other malicious activities. But how secure is the transfer of electronic mail? Email is unquestionably still the basis of many formal and informal business processes, and so as long as this is the case, it is going to be the target of malicious parties. The answer to the issue of email security is a simple one, but not so encouraging. The state of mail transfer security is not nearly as good as in the domain of web page transfers.\n\nThere are significant differences between mail transfer and web page transfer. Web page transfer is usually performed between a web client (browser) and a web server. Mail, on the other hand, is not usually transferred to the recipients by a mail client, but instead to the server of the sender’s mail provider. It then passes the mail to the mail server of the recipient’s email provider, and then finally the recipient will download it asynchronously from that server. As you can see, there is a server-server communication that cannot be influenced by either of the clients. The details of that communication are determined by the participant servers and the simple mail transfer protocol (SMTP), which was designed at the beginning of the 1980s to be simple, not secure. \n\n[Originally](https://datatracker.ietf.org/doc/html/rfc821), the protocol did not contain any encryption capability. However, the [opportunistic use of TLS](https://en.wikipedia.org/wiki/Opportunistic_encryption) was introduced in 1999, though only as an optional extension. Twenty years on, a publicly referenced server still must not be required to use the mechanism to deliver mail locally according to the related [RFC](https://datatracker.ietf.org/doc/html/rfc3207#section-4). It means that the owner of a recipient domain, notwithstanding a legitimate interest, is not allowed to require encryption during the mail delivery process. It depends on the sender’s goodwill to initiate encryption. Without it, both client and server are exposed to a malicious third party with [man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) capability that can enforce a lack of encryption, independently from the fact that both parties intend to encrypt. Without initiating encryption, the recipient cannot authenticate the sender and vice versa and beyond this, the mail transfer is vulnerable to eavesdropping and also content modification. Under such circumstances, the recipient may believe a sender is trusted and therefore believe that the attachment is trusted. However, the attachment could potentially be malware forged into the mail by a malicious third party.\n\n\n## Possible Solutions\n\nThere are several mechanisms like [BIMI](https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_Identification), [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities), [DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail), [DMARC](https://en.wikipedia.org/wiki/DMARC), [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions), [MTA-STS](https://datatracker.ietf.org/doc/html/rfc8461), [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework), [TLS-RPT](https://datatracker.ietf.org/doc/html/rfc8460), which have aimed to remedy the situation, with a greater or lesser degree of success. We will examine the theories behind these mechanisms, their practical limitations, configuration difficulties, and the achieved effect. \n\n![Mail server related DNS records](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=359061435&format=image)\n\nIn general, it can be said that the most important limitations are prevalence and enforceability. As can be seen from the chart, there are significant differences in prevalence if we compare the top 1,000, 100,000, and one million domains of the [Majestic Million](https://majestic.com/reports/majestic-million). The prevalence is much higher among the most popular domains than the others. The reason cannot be only the fact that the Fortune 1,000 companies enjoy much better financial conditions, as these mechanisms can be implemented without significant cost. The lack of knowledge could be one reason, even though there are several guides and easy-to-use tools available to get the necessary configurations to enable these mechanisms. Another reason might be the fact that there is no regulatory body that can enforce the usage of these mechanisms or the execution of the policies declared by these mechanisms, only recommend them, as [NIST does](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf). The last reason to mention is that domain owners also have no power to force the execution of the declared policies on the mail systems owners of the recipient side. In any case, big tech companies like Google, which has a significant market share of the mail service market, have begun to put pressure on domain owners who want to provide mail service for their domain to publish policies, although [they do not necessarily strictly comply](https://security.stackexchange.com/questions/239152/does-gmail-still-ignore-dkim-if-spf-passes-dmarc-style) with them.\n\nIn summary, the lack of these mechanisms on the sender side means a relatively high risk that emails sent from the domain are going to be put in a spam folder or rejected, at least by the biggest mail providers. The lack of checking of the policies declared through these mechanisms on the recipient side may mean a relatively high risk of incoming mails coming from unauthorized, or even malicious actors who can impersonate trusted parties. Usually, impersonation is the first step of a targeted attack where fraudsters can inject misinformation or bogus content such as scams, viruses, spyware, and malware into the organization.\n\n\n### Sender Policy Framework (SPF)\n\n\n#### Concept\n\nThe sender side can publish a policy through this mechanism, declaring which servers are allowed to send mail in the name of the given domain. The recipient side can use the published policies to check that the incoming mail is actually sent by an authoritative server. The policy itself is published in a TXT record of the given domain (e.g. example.com) and the servers can be declared by their IP addresses or indirectly, referring to other DNS records. The simplest case, at least in this respect, is that the domain owner maintains its email server and the MX record of the domain contains the IP address(es) of the mail server(s), so only the MX record should be referred to. From other points of view, it may seem easier to use a software-as-a-service solution to implement your mail service. In that case, you can include the policy of the SaaS provider or you can simply redirect to it.\n\n```\nexample.com. IN TXT “v=spf1 mx -all”\nexample.com. IN TXT “v=spf1 include:_spf.google.com -all”\nexample.com. IN TXT “v=spf1 redirect:spf.protection.outlook.com -all”\n```\n\n#### Threats\n\nThe tricky part of a sender policy framework is not the explicit declaration of the servers, but the declaration of the default action. Default action answers the question of what should be done when the recipient realizes that there is no explicit rule that matches the IP address of the actual sender. For this, a special [mechanism](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.2) (`all`) can be used optionally with a qualifier. All the examples above use the fail (`-`) qualifier, so the evaluation result of the Sender Policy Framework will [fail](https://datatracker.ietf.org/doc/html/rfc7208#section-2.6.4) for clients not explicitly stated in the policy, meaning that they are not authorized to use the domain.\n\n![Sending Mail by a Server is not Included in the Policy will](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=148466378&format=image)\n\nAlthough default fail is considered the most secure method, only less than one-third of the SPF records use it. This may be because this is not the most convenient method from the perspective of maintenance, as the lack of an IP address may cause failure in delivery.\n\nThere are two other options to avoid this problem. Domain owners can explicitly state that they are not asserting whether the IP address is authorized or not. This can be done by adding the [neutral](https://datatracker.ietf.org/doc/html/rfc7208#section-2.6.2) (`?`) modifier. This might seem convenient in terms of the maintenance side, but has almost no added value on the security side. The result will be the same if the default is missing and the case is similar when the whole SPF record is missing. Counting all the MX records, not only the ones which have SPF TXT records, the ratio of neutral modifiers with a default value (all) is more than one-third. More than half of the SPF records use the soft fail modifier (`~`) when declaring the default behavior, meaning that the host is probably not authorized. From a security perspective, this is just a little more than if it were neutral.\n\nWhy is default action so important? Just imagine a firewall policy that contains a default rule declaring what should happen when no rule matches on the traffic explicitly when it could say that the traffic is not asserting or probably not authorized. It would be a security nightmare. Domain owners should know which servers are authoritative and should declare it strictly. In that case, the recipient can be sure that the sender is authoritative and the mail from a representative of a trusted company really comes from them, and as a result, avoid being a victim of a [phishing](https://en.wikipedia.org/wiki/Phishing) or [social engineering](https://en.wikipedia.org/wiki/Social_engineering_(security)) attack. Though strict rules may affect business continuity – something which must be taken into consideration – this issue should be handled by another mechanism, like DMARC, not by making the policy more permissive.\n\nA severe limitation of the Sender Policy Framework is that servers are authorized by their IP address(es), which is vulnerable to [IP spoofing](https://en.wikipedia.org/wiki/IP_address_spoofing), and they could be declared indirectly referring to IP addresses by hostnames or other DNS records which are vulnerable to [DNS spoofing](https://en.wikipedia.org/wiki/DNS_spoofing). As the policy is stored in a DNS record, it should be transferred in a way that can guarantee the integrity of the data: without [DNSSec](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) or at least DNS over [TLS](https://en.wikipedia.org/wiki/DNS_over_TLS)/[HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS), the policy information is vulnerable to tampering and altering. The most serious issue with the Sender Policy Framework is that while its prevalence is relatively high, the really important question is what the ratio of the enforcer servers is. In any case, though the Sender Policy Framework can improve the level of security, publishing a policy has only a modest effect, which means that it should be combined with other mechanisms as it can prove neither the integrity nor the confidentiality of a mail.\n\n\n### DomainKeys Identified Mail (DKIM)\n\n\n#### Concept\n\nIn comparison, a Sender Policy Framework makes it possible to determine whether the server is authoritative to send an email in the name of the given domain, whereas the DomainKey Identified Mail method can be used to authenticate the mail itself independently from what the IP address of the sender was. The sender inserts a header (`DKIM-Signature`) into the mail which contains at least the hash of the body (`bh`), the signature of the content (`b`), the list of the headers (`h`) included when the signature is computed, the algorithm (`a`) used to create the signature and location (`d`, `s`) of the public key which can be used to verify the signature.\n\n\n```\nDKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;\n     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;\n     h=from:to:subject:date:keywords:keywords;\n     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;\n     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR\n```\n\n\nThe recipient mail server simply decrypts the signature with the public key found in the given location. The fact of the success of the decryption proves that the mail was signed by an actor who owns the private key related to the public key used to decrypt the signature. The decrypted value is the hash of the original mail that has been computed by the signer module of the sender server. The recipient server recomputes the hash and compares it with the result of the decryption. If the two hashes are identical, the mail body (including the attachments) and the listed headers are guaranteed not to have been altered by a third party. This essentially means that there is no malicious attachment in the mail unless the sender has attached it and nobody has modified any data in the mail, for instance, an account number, committing an [email fraud](https://en.wikipedia.org/wiki/Email_fraud).\n\n\n#### Weaknesses\n\nChoosing the appropriate signature algorithm and public key size requires care with this mechanism, as a not-so-wise decision may make the efforts so far meaningless. The traditional RSA public key type, with at least a 2048 bit key size or any elliptic curve-based key with at least a 224 bit key size can meet expectations, according to NIST. As multiple keys can be set, you can configure either an RSA key for compatibility and an ECDSA for modernity and to enjoy the benefits of elliptic curve-based cryptography, like smaller key sizes. Signature algorithm SHA-2 with any message digest size could be suitable. However, SHA-1 is strongly contraindicated as [there is](https://sha-mbles.github.io/) a [chosen-prefix collision attack](https://en.wikipedia.org/wiki/Collision_attack) against this algorithm. It needs a high amount of computational power, which makes a real-time break almost impossible, even taking into account the average delay time of a mail, though there is an opportunity of a [replay attack](https://en.wikipedia.org/wiki/Replay_attack), where the attacker can send almost the same mail later with a modified bank account number and payment deadline while the signature is still valid. The weak point of the DKIM mechanism is not the cryptography, but the fact that DKIM cannot provide confidentiality. \n\n\n### MTA Strict Transport Security (MTA-STS)\n\n\n#### Concept\n\nMTA Strict Transport Security is intended to solve the confidentiality issue of mail sending. Though the SMTP protocol originally did not contain any encryption capability, later an optional encryption capability was added as an extension, which is still not required. The situation is similar in relation to the unencrypted HTTP and the encrypted HTTPS protocols. An attacker with man-in-the-middle capability is able to force a client to use the unencrypted HTTP if the connection to the server was initiated with that protocol independently of whether the server supports the encrypted HTTPS protocol or not. It means that all the traffic communicated between the parties, which may contain sensitive information, can be intercepted by the attacker. There is a condition that must be met for a successful attack to be carried out, namely that the server must support the unencrypted version of the protocol. HTTP is not necessarily present, but SMTP always is, which means the information that encryption can be used must reach the client. This is the Strict Transport Security, which is implemented as a header in case of HTTP and a DNS record publication in case of SMTP.\n\n```\n_mta-sts.example.com.  IN TXT \"v=STSv1; id=20210602165800Z;\"\n```\n\nDuring our investigation, we identified that most of the MTA-STS supporting domains use date in the id field. Assuming that the date in the id field is the publication date of the latest policy, and also assuming that the policies are not changing very often, a diagram can be drawn, in a cumulative manner, that shows how many MTA-STS policies were published. Though the curve may suggest a rise, the current prevalence does not even reach one percent.\n\n![MTA Strict Transport Security (MTA-STS) count](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=477050378&format=image)\n\nUnlike the HTTP protocol, the SMTP protocol cannot be redirected to an encrypted channel, as SMTP protocol does not contain something like the “[moved permanently](https://en.wikipedia.org/wiki/HTTP_301)” [response status code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) in HTTP, so the information that the server wants to use encrypted communication must reach the client on an independent channel. In this case, DNS is used, just like in Sender Policy Framework or DomainKey Identified Mail. Similar to the earlier mechanisms, MTA Strict Transport Security is published in a TXT record. The difference is that only the fact of presence and current version are indicated by TXT records, but the policy itself is distributed via HTTPS from a ‘[well-known](https://tools.ietf.org/html/rfc5785)’ source. The DNS record contains a short string(`id`) that uniquely identifies a given instance of a policy so that senders can determine when the policy has been updated.\n\n```\nversion: STSv1\nmode: enforce\nmx: mail1.example.com\nmx: mail2.example.com\nmax_age: 86400\n```\n\n\nThe policy is similar to the [Strict Transport Security header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) in the case of HTTP. It contains a list (`mx`) of servers by which mails for this domain might be handled, with a lifetime value (`max_age`) for the policy, meaning that a client can cache a policy for up to this value and a mode (`mode`) indicating the expected behavior of the sending server in the case of a policy validation failure. The policy may declare that the sending server must not deliver (`enforce`) the message to a server which fails hostname matching or certificate validation, or has no TLS capability. For testing purposes, there is a mode (`testing`) that makes it possible to deliver mails despite the fact that there was validation failure, but a sending server can send a report about the failure (see TLS-RPT later). There is also a mode (`none`) indicating that there is no active policy. Today, just over half of the owners of MTS-STS publishing domains want to enforce the policy, while the other half is presumably in a testing phase. However, it should be noted that the ratio of domains supporting MTA-STS in the top one million is only 0.7%.\n\n![MTA Strict Transport Security (MTA-STS) modes](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=1993289931&format=image)\n\n#### Threats\n\nPublishing MTA-STS policy is necessary, but far from sufficient. It should be enforced to minimize the risk of a MITM attack to ensure the unencrypted method of SMTP communication. Nonetheless, the existence and enforcement of the TLS protocol do not necessarily guarantee confidentiality. The quality and performance of the encryption is highly dependent on the details of the TLS settings. They should be determined and reviewed regularly with due care, bearing in mind the requirements of the related compliances ([NIST](https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final), [PCI DSS](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf), [HIPAA](https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html)) if necessary.\n\n\n#### Weaknesses\n\nTLS has a significant benefit, namely that it solves not only the problem of confidentiality but also the problem of integrity targeted by DKIM. However, it should be noted that the MTS-STS cannot guarantee confidentiality and integrity throughout the entire process of mail sending, despite [Pretty Good Privacy](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) (PGP) or [Secure/Multipurpose Internet Mail Extensions](https://en.wikipedia.org/wiki/S/MIME) (S/MIME) – just in respect of MTA communication, as the name suggests, so in the case of client (MUA) server communication, the same issues exist when a protocol has only opportunist TLS capability, just like IMAP and POP3. Disadvantages of the mechanism include the fact that it requires the maintenance of a web server to publish the MTA-STS policy independently of whether the domain owner intends to publish a web page or not, and also that it requires the maintenance of an X.509 certificate for that web server, as only HTTPS is allowed to download the policy.\n\n\n### SMTP TLS Reporting (TLS-RPT)\n\n\n#### Concept\n\nThough the topics discussed so far have been strictly related to security, we should also consider business continuity. Introducing the discussed mechanisms carries a risk in terms of mail delivery. The risk cannot be transferred and should not be accepted, as it can be reduced by the SMTP TLS Report mechanism declaring reporting endpoints where the sending servers can report when experiencing policy validation failures. The policy can be published in one or more TXT records that contain the aggregate report URI (`rua`), which can either be an email address or an HTTPS endpoint. \n\n\n```\n_smtp._tls.example.com. IN TXT \"v=TLSRPTv1; rua=mailto:reports@example.com\"\n_smtp._tls.example.com. IN TXT \"v=TLSRPTv1; rua=https://reporting.example.com/v1/tlsrpt\"\n```\n\n\n\n#### Weaknesses\n\nOne advantage of the mechanism is that it makes it possible to receive information about MTA-STS verification failures of sending mail servers, something which can be either a simple technical issue or an active attack. The disadvantage of the mechanism is that it may be necessary for the mail servers to use a protocol (HTTPS) that is unrelated to the mail sending and therefore requires extra functionality in the mail server implementation. Furthermore, the protocol has its own security mechanisms ([HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security), [Report-To](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-to), [Network Error Logging](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NEL), [Expect-CT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT), …) which should be supported as an HTTP client in a mail server to provide the highest available security level. Policy violation reporting based on mails requires properly configured DomainKey Identified Mail (DKIM) on the report sending mail server side. If DKIM verification fails on the side of the report recipient mail server, the report can be ignored, according to the RFC. However, the RFC does not discuss the fact that the Sender Policy Framework can also be checked, as the report is actually sent by a mail server in the name of a given domain. With these checks, the reporter can be authenticated in a slightly weak way though, as an attacker can buy a domain and can apply proper DKIM and SPF settings and to send misinforming reports. However, with that activity there is a risk that the mail server is going to be added to a blacklist. The other option, sending the report via HTTPS, provides a much better opportunity to the attacker to send misleading reports, as it is much harder for the recipient to authenticate the sender of the report. Maybe this is the reason why the vast majority of the domain owners have chosen reporting MTA-STS violation in mail, not via HTTPS. This means there is a risk that spoof reports will be sent by an attacker to generate false positive alerts, thus undermining the trust in these kinds of reports, which could indicate man-in-the-middle attacks against our mailing system.\n\n![SMTP TLS Reports Requested to be Sent](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=758652635&format=image)\n\n#### Threats\n\nAnother problem of the reporting is the fact that it is completely voluntary. Publishing a TLSRPT policy with an appropriate aggregate report URI (`rua`) value does not necessarily mean that you will actually receive any reports, as the recipient may or may not support the TLSRPT mechanism. Even if the recipient supports the mechanism, it is far from sure that the recipient supports report sending and also intends to send reports, as configuration and a certain amount of resources are required to do so. \n\n\n### Domain-based Message Authentication, Reporting and Conformance (DMARC)\n\n\n#### Concept\n\nThe relation between the previously discussed TLS-RPT and the MTA-STS is the same as the relations between DMARC and the Sender Policy Framework (SPF) or DomainKey Identified Mail (DKIM). When the verification of SPF or DKIM fails, the recipient mail server can send a failure report to the domain owner defined in the DMARC TXT record. Compared to TLS-RPT it can be noted that there are more sophisticated settings here. Not only a single type of reporting endpoint can be set, but one for aggregate feedback (`rua`) and another for message-specific failure information (`ruf`). Report interval (`ri`) can also be set to indicate a request to mail receivers to generate aggregate reports separated by no more than the requested amount of time, and last but not least a policy is published as part of DMARC applies to the domain and can also apply to subdomains. The domain owner may request mail receivers to take no specific action (`none`) to treat mail that fails the DMARC check suspicious (`quarantine`) and place them into a spam folder, for instance, or to reject (`reject`) email that fails the DMARC check.\n\n```\n_dmarc.example.com.  IN TXT \"v=DMARC1; p=reject; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com\"\n```\nThe ratio of the required actions dramatically shows how heavily the business depends on the email systems and how much more important the business continuity is than the security. Using a security first mindset any mail that fails the DMARC check would be treated as suspicious and should be quarantined or rejected. Except for the top 1,000 domain owners, only the minority are brave enough to ask the mail receivers to quarantine or reject. In other cases, the majority asks the mail receivers to take no action which questions the usage of DMARC has any sense.\n\n![Domain Owner Wishes for Mail Receivers to take the action if DMARC check fails](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=1607294539&format=image)\n\n#### Weaknesses\n\nAuthenticating the issuer of the report is as hard as it is in the case of SMTP TLS Reporting (TLS-RPT), so there is a risk that the reports will be spoofed. Despite the TLS-RPT, DMARC supports only delivering reports by mail, so authentication of the sender is possible, but only in a limited manner.\n\n\n#### Threats\n\nIncidentally, a situation is conceivable when there are two servers which support DMARC and intend to send reports when experiencing an issue, but the DMARC fails mutually during the check of the reporting mail due to a DMARC configuration or DMARC check implementation issue. In that case, the DMARC report send is triggered mutually by the DMARC report of the other server, which could potentially cause an endless loop. There are also limits to DMARC specification, like percentage (`pct`) of messages to which the DMARC policy is to be applied, or the earlier mentioned report interval (`ri`), but these options are designed to help the introduction of DMARC, not to avoid attacks. \n\n\n### Brand Indicators for Message Identification (BIMI)\n\nThe mechanisms discussed above are about machine-to-machine (M2M) communication. There are no – or no well-declared – user-facing consequences of success and failure. BIMI seeks to fill this gap, and makes the result of the earlier mechanisms visible to the user. BIMI enables the display of brand-controlled logos within supporting email clients (MUA) only if the email is well authenticated. This essentially means that the sender domain must publish DMARC for the domain and the subdomains, where the policy must be set to either quarantine or reject and where the percentage subdomain policy cannot be set to anything less than 100. For the brand’s logo to be displayed in the email client, the email must pass DMARC authentication and BIMI validation checks, ensuring that the organization’s domain has not been impersonated and the brand indicator is valid.\n\n```\ndefault._bimi.example.com.  IN TXT \"v=BIMI1; l=https://example/bimi/logo.svg\"\n```\n\n#### Weaknesses\n\nThe configuration is relatively simple compared to the previously described mechanisms, but it must be noted that there could also be a relatively simple attack against it. Once the logo is published, a malicious actor could register a lookalike domain, configure DKIM, DMARC and copy the indicator to mimic the attackable domain and publish it as if it were its own. In that case, the same logo would appear in the email client of the recipient as the email coming from either the attacked or the attacker domain, so for the recipient it is just as hard to distinguish the two domains as it was before. The situation is much worse when the attacked domain does not publish BIMI, just the attacker one, so the latter may seem more trustworthy than the former. This weakness is targeted by the Verified Mark Certificates (VMC), which provide digitally signed evidence that the organization is allowed to use the brand indicator, like the extended validation where not only the domain but the organization name and other descriptive data are certified. The mechanism is based on X.509, so it carries all the complexity and difficulties of it, including validation, revocations checking and certificate transparency. Verified Mark Certificates can only be purchased by an organization if their logo is trademarked, so it is feared that the VMC part of BIMI takes us back to pre-Let’s Encrypt times, when there was no chance of signing a certificate with a widely accepted certificate authority for free, meaning it cannot reach high prevalence, just like extended validation.\n\n\n### Domain Name System Security Extensions (DNSSEC)\n\n\n#### Concept\n\nDNSSEC is a suite of extension specifications for securing data exchanged using the DNS protocol in untrusted networks, just like the internet. DNSSEC ensures the authenticity and integrity of data, but not confidentiality. As the information stored in DNS records related to the previously discussed mechanisms (SPF, DMARC, DKIM…) are public, confidentiality is not required, but authenticity and integrity are, meaning that we need to be sure that the information is not compromised by an attacker. [DNS over TLS](https://en.wikipedia.org/wiki/DNS_over_TLS) (DoT) and [DNS over HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS) also provide authenticity and integrity in addition to confidentiality, but DNSSEC has a significant advantage over them, namely it can ensure authenticity and integrity during the potentially recursive name resolution procedure. DoT and DoH can provide confidentiality, integrity and authenticity between the DNS client and the DNS resolver, but it is not possible to ensure that all DNS servers use DoT/DoH when serving the request and the client has no information about whether they used DoT/DoH or not. It must be noted that these two protocols were never intended to achieve that goal, but instead to provide confidentiality and also privacy to the end-user. \n\n\n#### Weaknesses\n\nIn the case of DNSSEC, integrity and authenticity are ensured by digital signatures. Answers from DNSSEC-protected zones are digitally signed by a key whose public part can be found in the DNSKEY record of the given domain. Using this public key, a DNS client can check the integrity and authenticity of the answer. Just like any other cases where integrity and authenticity are ensured by digital signatures, the key issue is the [chain of trust](https://en.wikipedia.org/wiki/Chain_of_trust) and also key types, sizes, and digest algorithms used in the chain. Public keys found in DNSKEY records are signed by the DNSKEY of the upper level domain up to the top level (TLD) and the root domain. The parameters of these keys determine the security level. As DNSSEC is a relatively old protocol of the internet, and the earlier versions did not support strong encryption algorithms and large key sizes, so backward compatibility leads to the fact that small key sizes are still in use, however, large ones are also supported.\n\n![RSA Equivalent DNSSEC Key Sizes of Top Level Domains](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=1714537878&format=image)\n\nOnly an insignificant minority of the top-level domains currently use the 1024-bit RSA key as the strongest key. Mostly, 2048-bit RSA keys are used, though it must be noted that RSA keys with lesser key sizes are also used. The prevalence of [elliptic-curve](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)-based public keys (ECDSA), despite all their advantages, is particularly low among the top-level domains. Only 256-bit keys are used, where the RSA equivalent key size is 3072, neither greater key sizes, nor Edwards-curve Digital Signature Algorithm (EdDSA) curves are used, though the latter is now recommended. Digest algorithms do not follow the same pattern as key types and sizes did: backward compatibility has no significant effect. Only an insignificant minority offer the weekend SHA-1 algorithm. The majority of the top-level domains offer strong digest algorithms.\n\n![DNSSEC Digest Algorithms of Top Level Domains](https://docs.google.com/spreadsheets/d/e/2PACX-1vSfbdF6Rpg_BlbLj6riHyWsUJjDxyZS-Hx5v1BZLeHAb-qZHSW4D1qCEz-Y6vFMJkGh6OL2eRLqjX9w/pubchart?oid=303158640&format=image)\n\nIt should be noted that the prevalence of DNSSEC is unfortunately low despite NIST declaring that organizations should deploy DNSSEC for all DNS name servers and validate DNSSEC responses on all systems that receive emails  to provide authentication and integrity protection to the DNS resource records discussed above.\n\n\n### DNS-based Authentication of Named Entities (DANE)\n\n\n#### Concept\n\nDANE is a protocol that allows binding X.509 certificates to domain names using the previously discussed DNSSEC. The most important result of binding domain names and X.509 certificates is that it makes any [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) (CA) needless, as it can declare an X.509 certificate or public key used on a specific service (for instance an email server) of the domain. In this case, an X.509 public key does not need to be certified by a third party (CA) that the X.509 public-key relates to a specific domain. As part of the issuance of a [domain validated certificate](https://en.wikipedia.org/wiki/Domain-validated_certificate), the domain owner must prove its authority to the certification, mostly by creating a DNS record with a specified value. However, in the case of DANE, a TLSA record has already been created to store the public key or its hash, so the authority is proven by matching the public key or X.509 certificate in the DNS record and provided by the service. The mechanism also makes certificate common name and subject alternative name (SAN) matching needless, as the certificate and the domain name are bound by a DNS record related definitely to the domain name. This means there is no need to certify the binding by a certificate authority as it is cryptographically proven by DNSSEC. Certificate revocation check, which is the [Achilles heel of the complete Public Key Infrastructure](https://coroner.medium.com/why-do-certificate-revocation-checking-mechanisms-never-work-f9b7a4ee1a61) ([PKI](https://en.wikipedia.org/wiki/Public_key_infrastructure)), also becomes needless, as the validity of a certificate has no sense in this environment: there is no certification by a third party that could expire, and the domain owner simply stops publishing a key if it is suspected to be compromised. The situation is the same when the domain owner just wants to regularly change keys to decrease their validity period, as it would be strongly recommendable, and now [blocked by the certificate authorities](https://www.thesslstore.com/blog/ssl-certificates-one-year-max-validity-ballot-fails-at-the-ca-b-forum/) despite the several weaknesses of revocation check mechanisms. \n\n\n```\n_25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )\n```\n\n\nThe previously emphasized way of working does not mean that DANE cannot work together with PKI. TLSA records have four data fields: certificate usage (2), selector (0), matching type (1), and certificate association data respectively. Certificate usage specifies that certificate association data contains a leaf certificate (end entity or EE) or a CA (trusted anchor or TA) and also specifies whether the certificate given by the server should be issued by a CA trusted by the application doing the verification (PKIX) or not (DANE). Certificate usage can take the following four values, where the certificate provided by the server during the TLS handshake must:\n\n1. be issued by an already trusted CA whose certificate published in the certificate association data (CA constraint or PKIX-TA)\n2. be issued by an already trusted CA whose certificate must match exactly the certificate published in the certificate association data (Service certificate constraint or PKIX-EE)\n3. be issued by the CA published in the certificate association data (Trusted anchor assertion or DANE-TA)\n4. match exactly the certificate published in the certificate association data and it can be a self-signed certificate (Domain issued certificate or DANE-EE)\n\nSelector specifies whether the full certificate (0) or the subject public key info are part of the certificate sent by the server should be matched against the association data, while matching type specifies how the certificate association data is presented. The entire selected data can be presented either in the certificate association data (0) or by a hash (1/2).\n\nDANE would mean a giant leap in the direction of a decentralized internet that preserves the support of the traditional PKI by providing some kind of digital self-determination for the domain owner. At the same time, it would also solve the problem that clients now trust in a predefined group of root CAs, where the members of the group depend on the vendor of the client application, independently from the fact that the domain owner trusts in only one CA that actually issued the certificate used by a server. Supporting DANE constraints could be applied to a number of trusted CAs – including the number zero, meaning that a domain owner could decide to skip CAs entirely.\n\n\n#### Weaknesses\n\nDespite all the advantages of DANE, there is one unavoidable disadvantage, namely the [lack of client application support](https://caniuse.com/dnssec), something which makes DANE a theoretical solution only to several serious practical issues.\n\n\n## Conclusions\n\nGiven the serious shortcoming of the old fashioned mail transfer protocol, it is strongly recommended to arm email systems with as many additional security mechanisms as possible, according to NIST which recommends organizations to deploy SPF, MTA-STS, DANE, and DNSSEC in order to avoid receiving mail from unauthenticated sources on an unreliable channel. There are, however, overlaps between the discussed mechanisms, all of them are needed to ensure the complete confidentiality, integrity, and authenticity of the received mails and also to be aware of whether senders are experiencing any suspicious behavior. The discussed mechanisms have no significant introduction or maintenance costs, especially given their undoubted benefit. Organizations should declare policies to help each other make informed decisions. These policies are about what servers are authoritative to send emails by the name of their domains (SPF) and whether they want to use encryption (MTA-STS, DANE) to ensure confidentiality when receiving mails, what the evidence is that a received mail has factually been sent by sender (DKIM), and how parties can inform each other when they experience errors or suspicious behaviors (DMARC, TLS-RPT). They also have to prove the integrity and authenticity of these policies (DNSSEC). This means that the “never trust, always verify” principle of the [Zero Trust Security Model](https://en.wikipedia.org/wiki/Zero_trust_security_model) is essential to filter out any suspicious senders and their deceptive content and malicious attachments, ideally before such content can cause a business email compromise.","date":"January 18, 2022","id":"Blogposts_15","short_description":"Google lists 12,400,000 results to the search of \"malware detection tools.\" Is malware detection a silver bullet, or is there a smarter method to prevent malware attacks? We believe there is one.","isEnglish":true,"isHungarian":true,"slug":"modern-techniques-to-prevent-malware-instead-of-detecting-it","title":"Modern Techniques to Prevent Malware instead of Detecting It"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/ddos_header01_c27982cac3.jpg"},"content":"Ransomware is a well-known term and one of the major cyber-enemies of organizations worldwide. But have you ever heard of ransom DDoS? This emerging threat is knocking on the doors, or rather the TCP ports, giving us another example of how cybercriminals are adapting to their victims’ IT infrastructure and cyber defense. In fact, ransom DDoS is not a kind of new attack – we have seen many such incidents in previous decades. It usually starts with a stream of non-legitimate HTTP requests from various sources, then follows with an email that requests a considerable sum of money to stop this activity. Back in the old days, such an attack was devastating, as the digital service would come to a halt and there was no real protection on hand. Later, cloud-based load balancers such as Cloudflare provided a good solution for even the smallest companies. \n\nBut DDoS is back. As the [Internet Organised Crime Threat Assessment (IOCTA) 2021 report](https://www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2021) from Europol states, “Law enforcement and private partners are reporting a re-emergence of DDoS attacks accompanied by ransom demands, as well an increase in high-volume attacks compared to the previous year.” That is also confirmed by Cloudflare in its [DDoS Attack Trends for Q3 2021 report](https://blog.cloudflare.com/ddos-attack-trends-for-2021-q3/), stating that “Cloudflare observed and mitigated record-setting HTTP DDoS attacks, terabit-strong network-layer attacks, one of the largest botnets ever deployed (Meris), and more recently, ransom DDoS attacks on voice over IP (VoIP) service providers and their network infrastructure around the world.” According to [Kaspersky’s statistics](https://securelist.com/ddos-attacks-in-q3-2021/104796/), “Q3 was unusually explosive for the number of DDoS attacks.” Something has changed and DDoS is at center stage once again. \n\nThis ’something’ is the modus operandi. First, the attackers seem to have a new botnet type. While the good old Mirai botnet is still infecting IoT devices and [now exploiting a vulnerability in Realtek chips](https://www.theregister.com/2021/08/25/mirai_botnet_critical_vuln_realtek_radware/), a new family, [Meris, is targeting a vulnerability in MikroTik routers](https://blog.cloudflare.com/meris-botnet/). The botnet of routers is much more powerful than a network of IoTs with quite weak hardware. Second, the attack methodology has also changed. As it was reported by both Cloudflare and Kaspersky, the average DDoS lasts only one or two hours. During this short period, the operation can be disrupted, but effective countermeasures can’t be implemented. As many companies received an email that demanded two bitcoins as a ransom before the attack, it is possible that the attackers were trying to prove that their intentions are serious. Third, the victims are not solely traditional targets. Online gaming platforms, media providers, political groups are among those targeted. Fourth, the attackers are well-prepared. We can clearly see that the TTP of state-sponsored groups is appearing at the criminal groups as well. This is obvious in the case of ransomware. But the same trend is also visible in DDoS ransoms. A crime gang behind some DDoS even [calls itself “Fancy Lazarus”](https://threatpost.com/fancy-lazarus-cyberattackers-ransom-ddos/166811/), reflecting the Russian-based Fancy Bear and the North Korean Lazarus groups. \n\nAs a fifth new trend, we should mention amplification. If a DDoS is targeting a specific device in the IT infrastructure, the result is a far more effective attack. This specific device nowadays is the ’security box’. More precisely, it attacks “targets security devices located between the client and the server (so-called middleboxes) — firewalls, load balancers, network address translators (NAT), deep packet inspection (DPI) tools and others,” as revealed by Kaspersky in its Q3 report. This middleware is sometimes an unexpected device. As Cloudflare says: “HTTP attacks against API gateways and the corporate websites of the providers have been combined with network-layer and transport-layer attacks against VoIP infrastructures.” \n\nWhy is an API gateway an interesting target? A lack of resources and rate limiting is the fourth major problem in [OWASP’s API Security Top 10](https://owasp.org/www-project-api-security/): “Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force”. If the API gateway is not able to manage this aspect, it leaves a huge attack surface towards even a small-scale DDoS. We at Balasys believe that an API security solution should support proper resource management and we do everything to protect API interfaces from DDoS. ","date":"December 6, 2021","id":"Blogposts_14","short_description":"The emerging threat of ransom DDoS attacks is knocking on the doors, or rather the TCP ports, giving us another example of how cybercriminals are adapting to their victims’ IT infrastructure and cyber defense.","isEnglish":true,"isHungarian":true,"slug":"are-ransom-d-do-s-attacks-coming-back","title":"Are ransom DDoS attacks coming back?"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/figure_design04_3b5b54bac7.png"},"content":"If we wanted to highlight the two most serious cyber threats of 2021, they would undoubtedly be ransomware and supply chain attacks. According to data from the Information Commissioner’s Office in the UK, 22% of reported cyber incidents were ransomware in H1 of 2021, which is double in comparison to the previous year. We can mention the notable Colonial Pipeline or JBS cases, which have set alarm bells ringing among cybersecurity experts. Supply chain attacks are not as visible as ransomware, as they stay under the radar, because they are mostly used by nation-state actors who want to steal information or prepare for a large-scale cyber operation. The Solarwinds attack is a good example of this attack vector.  \n\nThe one-million-dollar question is, how can we defend ourselves? Ransomware groups are always able to find that one person who will click on that one PDF file with a payload. APT groups have almost unlimited resources to carry out a supply chain attack. Meanwhile, organizations have a very limited budget and technology for defense. Even the well-resourced U.S. government had to admit that it can’t protect the federal IT systems and needs to improve both legislation and human/technology resources.  \n\nOne of the major advantages of the U.S. government is that it can write legislation and provide money for technology. On 12 May 2021, U.S. President Joe Biden announced his Executive Order 14028 on Improving the Nation’s Cybersecurity. Its major message is that “the Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks, and invest in both technology and personnel to match these modernization goals.”  \n\nSurprisingly, none of the above-mentioned technologies are new. Cloud technology has been widely used for more than ten years. The Zero Trust security model is even older; it was first mentioned in 1994, though it became widely known at the beginning of the 2000s. Widely known, but not yet that popular. The reason is that the adaption of the Zero Trust principles requires the redesign of the whole security architecture. CISA’s Zero Trust Maturity Model defines seven requirements for a Zero Trust architecture:\n\n1.\tAll data sources and computing services are considered resources.\n2.\tAll communication is secured regardless of network location.\n3.\tAccess to individual enterprise resources is granted on a per-session basis.\n4.\tAccess to resources is determined by dynamic policy.\n5.\tThe enterprise monitors and measures the integrity and security posture of all owned and associated assets.\n6.\tAll resource authentication and authorization are dynamic and strictly enforced before access is allowed.\n7.\tThe enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.  \n\nThough Zero Trust is more about cultural change than tons of new products, that doesn’t mean it is a completely painless process.  Even so, it’s the right time to start this cultural change. It is true that it perhaps should have been done at the beginning of the last decade, when end-users first began using their own devices (BYOD). Mid-2010 might also have been a suitable time, as companies started turning to the cloud. The good news is that we also have momentum in this area currently, as remote working has become the new norm in the last one-and-a-half years thanks to COVID. When everything is traveling in the same direction anyway, why not begin implementing Zero Trust now? Current threats can’t be managed without Zero Trust, legislation requires its implementation, and digital infrastructures are shifting to a more inclusive setup. And when it comes to digital infrastructure,  although we wrote that the Zero Trust principle is more of a cultural change than a new technology,  it doesn’t mean there aren’t advanced products that could help with the transition. We at Balasys are working on and with technologies that are perfectly suited to this kind of architecture.\n","date":"October 18, 2021","id":"Blogposts_12","short_description":"In the age of ransomware and supply chain attacks, how can organizations defend themselves? One of the possible answers is Zero Trust.","isEnglish":true,"isHungarian":true,"slug":"why-is-zero-trust-more-important-than-ever-before","title":"Why is Zero Trust more important than ever before?"},{"author":"Szilárd Pfeiffer, Security Evangelist & Engineer, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/figre_design03_169_fe0c038c56.png"},"content":"**In theory, it isn’t particularly new. The term zero trust [has been around for](https://dspace.stir.ac.uk/bitstream/1893/2010/1/Formalising%20trust%20as%20a%20computational%20concept.pdf) more than 55 years. **[De-perimeterisation](https://en.wikipedia.org/wiki/De-perimeterisation)**, the main concept behind Zero Trust Architecture, was defined and promoted on the [Jericho Forums](https://en.wikipedia.org/wiki/Jericho_Forum), which was founded 20 years ago. Even the [management of risks associated with de-perimeterisation](http://www.ma.rhul.ac.uk/static/techrep/2009/RHUL-MA-2009-07.pdf) were discussed almost two decades ago. **[John Kindervag](https://www.linkedin.com/in/john-kindervag-40572b1/)** coined the concept while he was at Forrester in 2009, and Google implemented a Zero Trust Architecture framework, referred to as [BeyondCorp](https://beyondcorp.com/), in the same year. Even so, in practice Zero Trust should mean more, than just a marketing hype, especially given that **[Joe Biden has ordered](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)** that “the Federal Government must adopt security best practices; advance toward Zero Trust Architecture”. The **[publication](https://www.nist.gov/publications/zero-trust-architecture)** of NIST can serve as both a theoretical and practical guideline, which should be applied to achieve worthwhile changes. But what are these theories and practices and why they are so important? Let’s take a look.**\n\n\n# What is Zero Trust?\n\nIt should be pointed out that Zero Trust is not a product, but a model. Though it can be facilitated by one or more products, it primarily necessitates a change in approach. Before, common sense was that a private network has definite perimeters with a small number of entry points, and the goal was to protect them. This way of thinking bears the strategic approach of the late medieval and early modern period. The defense of an area with definite boundaries and the assets concentrated behind the walls of the fortress. Both attacking and defending armies were mostly focused on the entry point, just like red and blue teams are focused on network defense tools in this castle-and-moat (network) security model. However, it is well-known, as it was in the medieval period, that there is a much easier and more profitable way than a siege, namely sabotage. In the castle-and-moat mode, if the authentication is circumvented at the entry point there are no other mechanisms to prevent malicious activity, as you are inside the perimeter. You are trusted if you are inside the perimeter – this could be the motto of any malware developer. Zero Trust Architecture is looking to overtake this old-fashioned perimeter approach. Before, there was a dogma that it was hard to obtain access to private resources from outside the private network, so successfully authenticated users could access any resources on the private network. In the age of virtual private networks (VPN) and cloud services, private resources can be obtained very easily from the internet, as there are no definite perimeters, with just a small number of entry points. This means that the way we defend the assets of the organization should change. Any access to any resources by any user or machine must be authenticated and authorized independently of whether the resource tried to be accessed from inside or outside of the organization’s private network. Zero Trust means that lack of authentication means no trust is given at all. Access can be given after successful authentication, but in a restricted manner, just like in real life. Network security is no different from other types of security: it uses the same tenets and learns from the history of them all, as discussed above.\n\n## Everything is a Resource\n\nZero Trust Architecture requires us to consider all data sources and computing services as resources, with no exceptions, even if the network might be composed of multiple classes of devices. Practically speaking, this means there should be one or more control points (Policy Enforcement Point) in the network where all the network traffic goes through and where the policy can be enforced. As a result, the castle-and-moat security model is completely inadequate. With Zero Trust, there is no resource concentration, no definite perimeters, and the focus is on the traffic paths of the communication instead of entry points.\n\nAs traffic paths can be controlled comprehensively in computer networks, there is no need to control the entry point itself. It is necessary to segment the network as much as possible and separate these segments from each other. This technique is known as micro-segmentation, as it creates several micro-perimeters or segments in the network. As the crossing between these micro segments are controlled and transit is permitted in a restricted manner, accurate authentication and authorization can be performed at the borders. The situation is the same as it is with real life borders, except that there are no – or at least there shouldn’t be –[green borders](https://en.wikipedia.org/wiki/Green_border) in computer networks. [Lateral movement](https://en.wikipedia.org/wiki/Network_Lateral_Movement) cannot be performed in the network as it is no longer hierarchical, and there are no resources of distinct importance, as all resources are treated equally, meaning access to all resources is verified independently from the classification of the resource, just like any passengers are authenticated at the borders independently of whether the passenger is a particularly important person or not.\n\n\n## Secure Communication\n\nSecure communication is an essential part of the Zero Trust Security Model for several reasons. Secure communication provides confidentiality, integrity, and authenticity. Authenticity makes it possible for the communicating parties to identify each other, and also makes it possible for the Policy Engine to identify the source of communication. The Policy Engine can then make a decision about whether access can be granted to a resource for a given subject, which will be enforced at the Policy Enforcement Point. Confidentiality inhibits the passive attacker to get credentials or other valuable information by eavesdropping on the network, which can be used during an active attack. Integrity ensures that the communication cannot be altered without the knowledge of the communication parties, making it impossible to modify sensitive information, such as a bank account number or invoice amount, in order to add misleading information or fishing for part of the original content. \n\n\n## Session Based Access\n\nAccording to the Zero Trust tenets, access to the resources are granted in a session-based manner. Both authentication and authorization are session-based, and the users must be granted only the level of access needed to fulfill their role, which means we must follow the [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege). A session-based approach guarantees a time limitation, as the access to a resource is not necessarily granted in a subsequent session or with the same privileges, as privileges should also be limited to those that are strictly necessary, session by session.\n\n\n## Strictly Enforced Authentication and Authorization\n\nAs has already been mentioned, the basic concept is that no one is trusted by default from either inside or outside the network. Authentication and authorization are always checked at each access request before access is granted to an organizational resource, though a question arises of how a user can be authenticated. The most-used authentication mechanisms are indirect, meaning they cannot supply direct evidence to the user’s identity, just certain factors such as something the user knows (knowledge), something the user has (possession) or something the user is (inherence), assuming the exclusivity of knowledge, possession, or inherence. Single factor, like a password might be compromised, but the probability of compromising multiple factors with different type is negligibly low, which is why it is so important to use multi-factor authentication.\n\nOne fundamental problem of identification by knowledge is that if it is unchanged over a long time, just like a password or a certificate, and becomes compromised, it does not identify the user, yet the abuse is hard to detect. Credentials that change over a short period of time, such as a [Time-based One-Time Password](https://en.wikipedia.org/wiki/Time-based_One-Time_Password) (TOTP) are one option, but this solution cannot solve the problem on its own, as an attacker who has stolen the shared secret, which is also a long-term credential, can generate a valid TOTP. However, combined with a possession-based factor, this can help to identify the human itself instead of just their knowledge. This is especially true when accessing the TOTP generator with [software](https://en.wikipedia.org/wiki/Software_token) or [hardware](https://en.wikipedia.org/wiki/Security_token) tokens that can be accessed after an inherence-based identification, such as unlocking a mobile device or a security token by fingerprint.\n\nHowever, for the user, or client in general, identification is just one factor in dynamic polices. The identification process can also encompass any associated attributes assigned by the enterprise to an account. Characteristics of the device used by the client, such as software versions installed, patch level, network or physical location, time and date of request and previously observed behavior, can also be part of the verification of a client and can also determine the applied policy. Behavioral attributes can also be measured, and deviations can be checked against the observed usage patterns before access is granted to a particular resource. The sensitivity and the classification of the resource should also vary according to the conditions of the resource access. For instance, under certain circumstances only read-only access is granted to a particular resource, but after additional authentication, by a second or a third factor, read-write access can be provided. The situation here is the same as it is in physical security, where entering a higher classified place requires additional authentication. In terms of network and data security, higher data acts like a location in physical security. \n\n\n## Monitoring devices in real-time\n\nEstablishing a continuous diagnostics and mitigation (CDM) system is also a requirement of Zero Trust Architecture. Knowing the current security-related state of the network and the actors involved is essential, as restrictions should be applied on a client or a server when a security issue can be assumed to be related to them. For instance, if a device runs a service that has a remotely executable vulnerability which is currently unpatched, the access of the affected service should be limited until the service is patched to mitigate the vulnerability. To be able to do that, it is also necessary to have the information that there is a security issue in the organization. This information can come from a CDM system and may imply a change in the earlier mentioned dynamic policies once a security issue is recognized and subsequently fixed.\n\nAppearance of a new device on the network is a typical scenario where monitoring is essential, as rules must be applied to the network traffic of the newly appeared device. Zero Trust requires that we do not trust in a device just because it is inside the private network, so the rule could simply lead to a denial. However, it is also possible that only one path should be opened which makes possible to register the device on the network for the user, especially if it is a mobile or a bring your own device, which can access only a limited part of the network with limited privileges. Independently from the applied policies, the information about the fact that there is an unregistered device that has appeared on the network which tries to communicate is a must, as it could indicate a legitimate usage of the network, but also an illegitimate or at least a suspicious one.\n\nNot just the devices, but the network traffic they generate should also be monitored. As part of the incident management, during investigation we will need all available information. Before any incident occurs, changes in resource accesses may indicate a security issue. For instance, requesting a higher level of privilege during a resource access, like requesting writing permission instead of the ordinary read-only one, or requesting it from an unusual network location, like from a foreign country the organization has no connection with, at an unusual time, like at midnight in case of a colleague that works 9-to-5 , or trying to discover the network, may all indicate the presence of a malicious software that may generate input to the CDM, causing quarantine of the device to prevent the spread of ransomware, for instance.\n\n\n# Conclusion\n\nThe NIST does not articulate any requirements of network security in its Zero Trust publications that would not have already been articulated by others before, but it does so in a way that makes it possible to reach not only C-level executives, but also state leaders – as it has influenced the Biden Administration’s [plans for strengthening US cybersecurity](https://www.helpnetsecurity.com/2021/06/08/biden-us-cybersecurity/). Leading technology research firms, such as Gartner and Forrester, also [promote the Zero Trust](https://www.gartner.com/smarterwithgartner/new-to-zero-trust-security-start-here/) model, which makes the concept almost unavoidable on providers’ side and also generates hype about the topic. Beyond business considerations, we should keep the basic statement of Zero Trust in mind: there could be attackers both inside and outside of the organization, so we should never simply trust, but always verify and enforce the principle of least privilege.\n\nIf you want to learn more about Balasys' Zero Trust solution, please download our [white paper](https://balasys.hu/static/2f6535a81e94abba1d9c142cc86d3220/PNS_UC_Zero_Trust_security_ENG_web03_aeaca83173.pdf), or visit our [solution page](https://www.balasys.hu/en/solutions/network-security/).\n","date":"September 16, 2021","id":"Blogposts_11","short_description":"What are the theories and practices and why they are so important? Let’s take a look.","isEnglish":true,"isHungarian":true,"slug":"zero-trust-is-it-anything-new","title":"Zero Trust: Is it anything new?"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/key01_1_c10b30cf22.jpg"},"content":"In the July and August of 2021, no week went by without a new scandalous media headline about governments and Big Tech companies attacking the smartphones of citizens and actively creating a mass surveillance system á la George Orwell’s 1984. In July, the world became familiar with the NSO Group and the Israeli company’s Pegasus software, which exploits zero-day attacks on widely used endpoint platforms and was designed to aid the operations of law enforcement and anti-terror agencies. Unfortunately, some not-so-democratic regimes have also used this tool against their opponents, with, for example, investigative journalists and even the French president [Emmanuel Macron allegedly targeted by a North African agency using the Israeli tool](https://www.theguardian.com/world/2021/jul/25/emmanuel-macron-pushes-for-israeli-inquiry-into-nso-spyware-concerns).  \n\nIn August, Apple announced new features to help in the fight against child sexual abuse material (CSAM). According to the plans, Apple will scan its iCloud Photos service in the US to find pre-identified CSAM materials by their hash. As a separate feature, it will notify the parents if their child is sending or receiving nude pictures. These pictures would be identified by an automatic nudity filter and will be effective only if [parental control is set up](https://www.theverge.com/2021/8/10/22613225/apple-csam-scanning-messages-child-safety-features-privacy-controversy-explained). Many privacy experts are against this plan and signed an open letter, highlighting concerns that Apple would scan not only the cloud but the endpoint as well, thus bypassing the users’ privacy and privatizing surveillance rights from the state (https://www.businessinsider.com/apple-iphone-scan-open-letter-child-abuse-plan-5k-signatures-2021-8). Apple have denied they would carry out endpoint scanning, although the European Union is requiring exactly this step in planned new legislation (https://www.computerweekly.com/opinion/European-chat-control-child-safety-plans-threaten-end-to-end-encryption).  \n\nGovernments, companies and even the EU is moving in the same direction, and regularly state that end-to-end encryption is now so widely used that it is a huge obstacle for law enforcement to do their job. On the one hand, this level of encryption is good news: we have arrived at the era of secure internet. Encryption is everywhere, and internet traffic cannot be tapped by the secret services. The users, or citizens – to call them by another name – are using encrypted chat programs and preserving their privacy. On the other hand, it is clear that criminals are also using the same tools. Or, similar tools, we should say, as the EncroChat and later the [Anom services were specifically designed for organized crime](https://www.europol.europa.eu/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication). It is extremely hard for the cops to find the bad guys among the mass of information and collect evidence against them. The number of CSAM materials are skyrocketing and there is a feeling that society should do something against pedophiles using and spreading  these materials.\nWhat could the solution be? Should we let the agencies or Big Tech automatically scan our devices? Or should end-to-end encryption have a backdoor? In fact, neither is a good idea. Let us quote Bruce Schneier, who said this in 2005: “Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into [allowing the government to do anything with those four](https://www.schneier.com/blog/archives/2005/12/computer_crime_1.html).” Or our colleague, Szilárd Pfeiffer, who wrote this: “if someone has a way to access data that has been intentionally hidden from outsiders by IT tools by weakening the encryption process or installing backdoors, the [secret will cease to be a secret](https://pfeifferszilard.hu/2021/02/25/cryptography-weakening-a-tale-of-the-law-abiding-criminal.html).”  \n\nWe know that lawful investigation is not easy. We know that it requires a lot of effort, resources, and expertise. We also know both that most people are not criminals and that most criminals are not the smartest. Which is why we are against mass surveillance. We do however applaud the success of FBI and Europol achieved in the Anom case mentioned above. And although it is a grey area and we don’t really like it, the use of Pegasus-like targeted tools under proper, democratic legal control could also be considered acceptable. We also fully support the capability development of law enforcement to develop and carry out Anom-like operations.  \n\nAnd as a final, additional remark , we want to add something to this debate. Networks are still not 100% secure. Is all your TLS implementation in your organization working in the right configuration? Could you eliminate all SSL? Even in your APIs? If the answer is yes, you’re in a unique position, because the National Security Agency had to remind US agencies in January 2021 to do this as obsolete crypto in these protocols mean a [serious threat](https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF). Our experience is the same: lots of unsecure, yet hackable http connections are still in use. As a hypothesis, we assume that even criminals can misconfigure their assets. This means there is still place for network tapping and, as [quantum computers may become a reality](https://www.quantamagazine.org/first-time-crystal-built-using-googles-quantum-computer-20210730/), today’s end-to-end encryption could be circumvented in many ways. By the way, if you don’t want your own API to be wiretapped, ensure its secure communication by using [Proxedo API Security](https://balasys.eu/en/proxedo-api-security/). \n","date":"August 18, 2021","id":"Blogposts_13","short_description":"Government agencies and Big Tech companies want to automatically scan mobile devices to fight against terrorism or child sexual abuse materials. Should we let them do that? ","isEnglish":true,"isHungarian":true,"slug":"the-shadow-of-mass-endpoint-surveillance-is-the-network-already-secure","title":"The Shadow of Mass Endpoint Surveillance – Is the Network Already Secure?"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/coursera_logo_full_rgb_70ff1efd95.png"},"content":"The emergence of COVID-19 required immediate action in several areas. The primary objective of the measures carried out immediately at the start of the emergency was to protect the health of the public and to avoid harm, though their secondary effects could not necessarily be predicted. To create the conditions for distance learning and to develop remote working capabilities necessary to maintain the function of the economy, enormous modifications had to be made in a short timespan to existing IT systems, while the introduction of new software was also needed. At the same time, there was also a significant increase in the risk from several cybersecurity issues affecting both systems and users during this period.\n \nBased on the experience of digital education, a selected platform should have the following features:\n\n- It must meet European data protection requirements, generally speaking the GDPR\n- It must ensure the special protection of children's personal data\n- It should include some specific privacy-enhancing technologies\n- It should support incident management in case of misuse of the platform\n- The developer should patch any detected vulnerabilities as soon as possible\n- It should support institutional identity and access management\n\nAt Coursera, one of the largest distance learning platforms worldwide, we witnessed a failure of the latter point due to some bad APIs . According to the report released in July 2021, Checkmarx Security Research Team (https://www.checkmarx.com/blog/technical-blog/api-crash-course-broken-object-level-authorization-found-in-coursera/) made a detailed analysis on the APIs inside Coursera’s Vulnerability Disclosure Program and discovered multiple API issues, including “user/account enumeration via the reset password feature, lack of resources limiting on both a GraphQL and REST API, and a GraphQL misconfiguration.” Moreover, they even found Broken Object Level Authorization (BOLA), which is listed at the top of OWASP’s Top 10 API security issues (https://owasp.org/www-project-api-security/). Throughout this vulnerability, the researchers were able to retrieve and modify the user preferences. Coursera cooperated with Checkmarx and fixed the vulnerabilities before the public announcement.\n \nCoursera is another case that reminds us of the importance of API security, and it makes sense to highlight here some lessons learned from this story.\n \n**First,** personal data is everywhere. A modern digital service cannot operate without data. At first glance, this data might not be classic personal data like a name or address. However, we do construct user profiles from these data pieces, which means that they quickly become personal data, and are therefore in need of protection. Our advice is to keep your eyes on all your collected, transmitted, and even processed data to avoid any future problems.\n \n**Second,** Coursera has a bug bounty program, something that is still rare among those providing digital services. At Balasys, we highly recommend starting a bug bounty program or joining an existing platform. Do not give cybercriminals the chance to find vulnerable APIs in your service and sell the stolen information on the Darknet. It is far safer if capable people are working in a regulated cybersecurity framework without the risk of carrying out questionable activities.\n \n**Third,** Checkmarx has a great solution for secure application development. As their recommendation says, “Authorization issues are, unfortunately, quite common with APIs. It is very important to centralize access control validations in a single, well and continuously tested, and actively maintained component. New API endpoints, or changes to the existing ones, should be carefully reviewed regarding their security requirements.” Our experience is the same. Without a central API security management solution, these interfaces can quickly become a high-risk vulnerability on your digital service’s surface. If you want to learn more about API security, please visit our [solution page](https://balasys.hu/en/solutions/api-security/).\n \n","date":"July 21, 2021","id":"Blogposts_10","short_description":"A number of security vulnerabilities have been found and disclosed in the Coursera online learning platform. Csaba Krasznay summarizes the key learning points of the story.","isEnglish":true,"isHungarian":true,"slug":"what-can-we-learn-from-the-coursera-api-story","title":"What can we learn from the Coursera API-story?"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/wafpost_9aefa57025.png"},"content":"*In the past period, intensive development and background work have shifted our focus inward, resulting in poor communication when it comes to Proxedo Network Security news. We’re sorry about that! I would like to emphasize that the development of PNS is nevertheless ongoing! Thanks to these efforts, Balasys’ highly flexible, proxy-based network security suite now boasts an updated architecture, a renewed GUI and several new features. In this post, I’d like to summarize the key new features that have been added to the product since the 1.0. release.*\n\n## 1. TLS 1.3 support\n\nProxedo Network Security was one of the first IT security products to support the latest TLS 1.3 cryptographic protocol. You can encrypt non-encrypted or legacy internet protocols with the most advanced encryption standard currently available on the market. The security of the communication can be further improved by requiring strong authentication from the user. Based on this feature set, you can implement highly secure web browsing, mailing or even e-banking/e-commerce services over your less-secure internet infrastructure. Another potential use is the strong encryption of data stored in cloud services.\n\n## 2. Web Application Firewall (WAF)\n\nBased on the integration with Apache ModSecurity WAF, PNS can now inspect and analyze the content of encrypted and non-encrypted internet traffic to verify that it conforms to the standards of the HTTP(S) in use. Beyond detecting advanced attack vectors, it can also hide the vulnerabilities or development errors of the web servers. This is a reliable tool for protecting your organization's public internet services.\n\n![application_firewall.png](/uploads/application_firewall_e04f1c5c1b.png)\n\n\n## 3. ICAP support\n\nThe PNS can now support the [Internet Content Adaptation Protocol](https://en.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol) (ICAP). Thanks to ICAP support, PNS can integrate with several third-party security solutions such as DLPs, IDS/IPS and anti-malware tools, including multi-scan engines and sandbox-technologies. The above integrations can also be implemented via encrypted channels. This feature empowers you to build a custom and comprehensive threat management environment to protect your enterprise network.\n\n![pns_threat-management.png](/uploads/pns_threat_management_c789954495.png)\n\n\n## 4. Hostname-based rules\n\nMany websites (e.g. facebook.com) don’t have a fixed IP address, yet you still need to control access to them. In addition, sometimes you are not allowed to inspect certain types of encrypted traffic (from privacy or other reasons), but you may still want to gain some control over this traffic tool. In such cases, hostname-based decisions can help you: you can control the access to these sites based purely on their hostnames. Essentially, this is a special URL-filtering capability helping you set up rules solely based on the domain name information, without knowing the IP address or the outgoing traffic content. For example, you can leverage this function in the following cases:\n\n- *Denying access to unwanted sites, applications or content* – e.g. blocking movie streaming or adult web sites.\n- *Selective content filtering* – e.g. allowing Windows update services or internet banking traffic but scanning all the other content for viruses.\n- *Load balancing of encrypted traffic* – e.g. redirection of bandwidth-intensive YouTube traffic to the backup line.\n\n## 5. Connection rate limiting\n\nProxedo Network Security offers a rule for limiting network connection rates. This feature comes in especially handy when your site is under (D)DOS attack or there are enormous peaks in the everyday traffic. You can configure the product to prioritize the requests in such cases by serving more important transactions first, while limiting the bandwidth for others.\n\n## 6. Advanced Protocol Recognition\n\nPNS can automatically recognize certain protocols and services and can selectively handle these based on preconfigured connection rules. Currently, the supported protocols and services are as follows: HTTP, SSH, server certificate and Sever Name Indication (SNI).\n\n## 7. Form-based authentication\n\nThe PNS 1.0.5 supports form-based authentication in HTTP protocol. It can be presented to the user with an editable ‘form’ to fill in and submit in order to log into a given web application or service. You can even integrate it with your existing AD/LDAP database. Form-based authentication is a platform-independent and customizable solution to unify the web-based authentication process across your company, customers and partners.\n\n*We are continuing the development of [Proxedo Network Security](https://www.balasys.eu/en/proxedo-network-security) to make it the most customizable, reliable and resource-efficient network security suite available on the market today. From now on, we are going to post some important news about Balasys and the Proxedo product family on a regular basis. Stay tuned!*\n\n*[Learn more here.](https://www.balasys.eu/en/proxedo-network-security/)*","date":"June 22, 2021","id":"Blogposts_3","short_description":"Key new features that have been added to the product since the 1.0. release ","isEnglish":true,"isHungarian":false,"slug":"what-s-new-in-balasys-pns-1-0-5","title":"What’s new in Balasys Proxedo Network Security 1.0.5"},{"author":"Csaba Krasznay, Director of Cybersecurity Research Institute at University of Public Service","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/michael_geiger_JJ_Pqav_J_By_k_unsplash_7081b3cfe5.jpg"},"content":"*A year ago, when the whole world switched to home office and social distancing because of the pandemic, cybersecurity experts were primarily focused on managing the foreseeable effects of the sudden digitalization that had hit us. Threats such as large-scale cybercrimes that utilized the latest technologies, online frauds affecting small businesses and older internet users, ransomware campaigns hitting healthcare and education organizations, and the protection of companies that had become more exposed to security risks due to remote working. Although it was immediately visible that state-backed intelligence groups were also active in the cyberspace, no one could have guessed that a secret operation, which later became known as the SolarWinds hack, had been going on for several months. It was an event that US politicians compared to Pearl Harbor and 9/11 because it was so unexpected.*\n\nIn December 2020, when the United States was burning in the fever of the presidential election, the top priority for US cyber defense was to protect the electoral system from attacks by foreign countries, learning from the lesson of 2016 intervention attributed to Russia. In the meantime, however, a breaking news hit the media: FireEye, one of the most reputable cybersecurity providers, reveal that they had been the victim of a targeted attack of unprecedented sophistication aimed at stealing their intellectual property. After a brief investigation, it was revealed that the attack also affected many US federal institutions and numerous technology companies. The primary attack vector was a malicious code built into the SolarWinds Orion software used for network monitoring, which had been implemented across 18,000 companies worldwide. Soon, it became clear that while America was busy focusing on the election, a successful and highly extensive cyber-espionage operation was taking place under the radar.\n\n![michael-geiger-JJPqavJBy_k-unsplash.jpg](https://cdn1.photostockeditor.com/c/2902/laptop-macbook-pro-turned-on-electronics-electronics-image.jpg)\n\nBoth government and industry experts almost immediately attributed the attack to Russia, except for President Trump, who, as usual, pointed to China. Of course, the above-mentioned states immediately dismissed the charges – as they always do. This behavior is not uncommon, as cyber espionage largely takes place in a grey area of international law and its successes are not commonly declared in public. However, the attack required precise operational planning and high resources that could only be carried out by a state with a serious intelligence background. Microsoft estimates that 1,000 people took part in the operation, using a method that is still unknown today. The attackers got into SolarWinds’s software development processes to implement a backdoor in the March 2020 update that was only accidentally noticed by FireEye nine months down the line. \nThe operation itself had been going on since the fall of 2019, and the range of organizations involved had been carefully selected. These organizations were not attacked directly, but instead through their supply chain, highlighting the high number of suppliers used by a large company can expose that company to cyber threats. The malicious code used in the attack was carefully designed to remain hidden for years. Once the discovery had finally been made, as if by magic the attackers erased all evidence, another feat that indicates the serious operational security behind the action. As a result, clear attribution won’t be easy due to the careful covering up of potential technical evidence.\n\nAfter the SolarWinds breach, cybersecurity professionals felt they could do nothing but put their hands up, indicating that they didn’t really know how to deal with such attacks. The opponent simply had too many resources, and without significant state and secret service support, there was no chance of defending organizations from such attacks. That is why the steps that the Biden Administration has put forward are significant. They immediately announced retaliation for the attack and started deterring opponents from later attempts. They have also significantly strengthened the US Cybersecurity and Infrastructure Security Agency, which protects internal cyberspace. Finally, cybersecurity, which the Trump government treated with disdain, is now to be given a worthy place.\n\nBut it is true that we really can’t do anything against sophisticated cyber attacks? Should we admit our helplessness? Of course, the answer is no. It is the individual responsibility of each organization to be prepared for all relevant threats. Considering the SolarWinds hack, we propose the following seven steps:\n\n### 1. Rethink your risk assessment.\nDo you measure the risk of a nation state attack in an adequate manner? Are the profiles of your potential attackers still valid?\n\n### 2. Be aware of the risks of your supply chain.\nDo you have security controls over all your external partners and the software they use? (Do not forget the APIs, as these are usually left out of most assessments.)\n\n### 3. Make sure that your IT security team is no longer considered as a cost center.\nYour IT security team is vital to the survival of your organization. Invest in your team, or at the very least, do not cut its budget.\n\n### 4. Invest into software and application security!\nIf your company has an internal development team, create a designated role within the team for cybersecurity and provide them with the required resources.\n\n### 5. Be part of cybersecurity information sharing.\nCooperate with your national Computer Security Incident Response Team (CSIRT), join an Information Sharing and Analysis Center or (ISAC) – there are many ways of teaming up.\n\n### 6. Cyber threat intelligence should be an integral part of your security operation.\nIn general, technical CTI is sufficient, but if you are an integral player in the supply chain, old-school human intelligence can also support your cyber defense.\n\n### 7. Prevention is just one part of the cyber defense. Detection is equally important.\nDetection gives you a chance to discover what is happening in your IT environment. You may not explore a complete APT attack, but you’ll have some evidence that will help any investigation. Logs are essential, but traces of remote access via SSH or RDP can also support the investigation.\n\n*[See here how Balasys can help.](https://balasys.eu)*","date":"May 12, 2021","id":"Blogposts_7","short_description":"Let's learn from the SolarWinds hack!","isEnglish":true,"isHungarian":true,"slug":"7-tips-to-prevent-breaches-like-the-solar-winds-hack","title":"7 tips to prevent breaches like the SolarWinds hack"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/stock_market_03340f1bef.jpg"},"content":"*In the past year, COVID-19 has had a greater impact on work habits and security environments than any other health emergency in history. The upcoming years will undoubtedly have their challenges, but organizations that are aware of these risks and take steps to mitigate their impact will be well-positioned to secure their future growth.*\n\n### Prediction 1: Cyberwar on the surface\n\nThere will unquestionably be a reaction to the recent Solarwinds attack. But what will happen in the case of other cyber conflicts? As of now, more than 50 states have offensive cyber warfare capabilities. In the 2010s, experts said that there was a hidden war in cyberspace. In the 2020s, we predict that this war will become visible to the public, and that the superpowers positioning themselves in the cyberspace will cause negative effects for us all.\n\n\n### Prediction 2: AI and automatization in cybercrime\n\nCOVID-19 has caused a 15% rise in the number of social media users, with almost 5 billion people using the internet on a daily base. We can predict an additional 1 billion people to log on this decade. This is a massive number of potential victims for cybercriminals, who have already started to use automatization to reach their targets more effectively. AI-based attacks such as deep fake or chatbots will also be used widely to support health and cryptocurrency-related frauds, phishing, and ransomware, which have already skyrocketed.\n\n\n### Prediction 3: Literally deadly effects of supply chains\n\nReturning to Solarwinds, the hack was an indication of how vulnerable we are to supply chain attacks. But what might happen if the operational security of the attacker is not as professional as it was in this case? What if something goes wrong and starts a domino effect, including the massive outage of critical infrastructures? We predict that in parallel with the militarization of cyberspace, cyber operations will cause death in the physical space due to mistakes from hackers who have not accounted for the effects on supply chains.\n\n\n### Prediction 4: Vulnerable home offices after COVID-19\n\nEven if the pandemic ends this year, the home office will be here to stay. In addition to its unquestionable benefits, however, working from home also carries several risks. The legitimate demand for accessing company resources through the internet has dramatically increased. This has resulted in the introduction or extension of virtual private networks, remote access and cloud solutions, often in a hurry. It represents a completely new or increased threat surface for many companies, where not only the technology or the service, but also the client side can be attacked, something which is much harder to defend against. \n\n\n### Prediction 5: Humans remain the weakest link\n\nTraditional phishing techniques, such as social engineering, will remain among the most effective attack methods. Caused by social distancing, separation from colleagues causes information validation challenges, and uncertainty always facilitates fraudulent attempts. Because a significant amount of business processes still strongly depends on email communication, sending seemingly legitimate mails is an effective method for malicious actors to acquire sensitive information or persuade someone to take unintended actions that can have serious consequences. Strong authentication and verifiably encrypted communication methods are highly recommended, at least for confirmation.\n\n\n### Prediction 6: Zero Trust gains momentum\n\nZero Trust is the next logical step in the evolution of enterprise security. Cyber threats will not decrease in a post-COVID world, given the increased number of remote activities. Companies who have applied the Zero Trust principles will be able to react properly to the upcoming challenges. Or rather, to the challenges which are already here, inside our networks or in our trusted zones. These organizations will gain significant advantage over others, not just because attackers always go for the low-hanging fruit, but also because they will be more efficient in discovering and mitigating complex Advanced Persistent Threats (APTs).\n\n\n### Prediction 7: IDM goes to the cloud\n\nThe growing penetration of hybrid infrastructures is just the beginning. This trend will not stop here. Companies want to benefit from the cloud based operating model where possible (or at least they want this option to be available), which means in the next couple of years even one of the biggest taboos will be broken, namely the concept that an identity management system must always be located on-site. \nThe advantages of a cloud-based IDM system are obvious from the customer’s perspective:\n\n-\tSignificantly shorter implementation time\n-\tEasy provisioning of IDM environments (DEV, TEST, UAT, etc.)\n-\tDynamically adjustable hardware resources according to the current needs\n-\tSubscription-based licensing model\n\n\n### Prediction 8: API Security on the rise\n\nAs more and more services are developed and made available to the public through APIs (either driven by business strategies or regulations, such as the PSD2), API security is becoming increasingly important for companies.\nIn 2019, the OWASP Top 10 API Security Project was introduced, focusing solely on the most common, critical API security issues. Based on the statistics, including our own experiences, authentication and authorization of API clients will gain importance on the upcoming list. On the other hand, the growing popularity and severity of Server-Side Request Forgeries attacks raise concerns, as they can compromise even the strongest of authentications or firewalls.\n\n\n### Prediction 9: Privileged Access Management re-evaluated\n\nSecuring and managing privileged accounts has lately been a critical challenge for companies. The transition to working from home has sometimes been a forced effort, but companies have received a boost in confidence in terms of the effectiveness of their IAM and PAM strategies. \nMany of the existing PAM solutions promised that they can serve administrators and business managers even through remote operation. Now that the initial dust settled, companies are looking at what else these solutions can offer, and how a previous necessity can be turned into feasible business benefits.\nThere are three main PAM areas, which are expected to be in focus in the upcoming period:\n- Further adaptation of PAM strategies\n- Non-IT users (business users, contractors, developers) become privileged users\n- Machine identities (process automation and service accounts) increasingly involved in PAM\n\n\n### Prediction 10: The exposure of legacy industrial systems will grow\n\nICS (Industrial Control Systems) and OT (Operational technology) networks has been key targets for cyber criminals and nation states for the last decade, that is without question. We have witnessed serious incidents such as the cyber-attacks against the Ukrainian and US electricity networks. Without deep knowledge of cybersecurity and ICSs we would think that these attacks have ringed the bell for most companies using legacy OT devices and vulnerable ICS networks. However, seemingly, these incidents had a very little impact on the approach to cybersecurity of those who are the most vulnerable and affected. In the upcoming years, the cyber warfare will shift increasingly towards the cyber-physical systems, while the business need will further increase the exposure of unprotected OT and ICS systems.\n\n[Click here](https://balasys.eu/en/) to learn more about how Balasys can help you mitigate the above challenges.\n","date":"April 14, 2021","id":"Blogposts_8","short_description":"In the past year, COVID-19 has had a greater impact on work habits and security environments than any other health emergency in history. ","isEnglish":true,"isHungarian":true,"slug":"balasys-top-10-it-security-predictions-2021-2023","title":"Balasys TOP10 IT Security Predictions 2021-2023"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/miert_fontos_blog_1_a3dc3ed6bb.png"},"content":"*A digitális átalakulás korában kiemelt szerepet kap az ügyfelek, a cégek és a partnerek közötti gyors kapcsolattartás és adatcsere. Ez a nyilvános API-k (Application Programming Interface-ek) számának robbanásszerű növekedését eredményezi. Az API-k olyan HTTP-alapú alkalmazásintegrációs protokollok amelyek elérhetővé teszik az alkalmazás adatokat a kapcsolódó felek, eszközök és szolgáltatások számára. Manapság az API-k több tízezer webes és felhőszolgáltatást, mobil- és IoT eszközt kötnek össze, és lehetővé teszik a zökkenőmentes gép-gép kommunikációt.*\n\nAz API-k már nem csak Facebook üzeneteket közvetítenek többé. Hatalmas mennyiségű érzékeny információ is továbbításra kerül ezeken az interfészeken: személyes azonosítók, pénzügyi és orvosi adatok, üzleti titkok, stb. És ezen adatok száma ugrásszerűen nő. Az API-k tehát közvetlen kiskapuként használhatók a vállalati rendszerekbe való bejutáshoz. Ennek eredményeként az API-infrastruktúrák elterjedése komoly biztonsági kihívásokat jelent. Ebben a posztban az API-kommunikáció biztonságával kapcsolatos legfontosabb szempontokat foglaljuk össze, és felvázolunk egy lehetséges megoldást.\n\n![miert-fontos-blog-1.png](/blog/miert-fontos-blog-1.png)\n\n## A támadók figyelme egyre inkább az API-kra összpontosul\n\nAz API-kon keresztül továbbított bizalmas adatok mennyisége gyors ütemben növekszik, ezáltal az API-k egyre inkább a támadók elsődleges célpontjává válnak. A sebezhető, hibás API-k felkutatásával képesek bejutni a bizalmas adatokat tároló háttérrendszerekbe. Ráadásul ezek a támadások egyre sikeresebbek. A közelmúltban történt nagyobb adatlopások közül sok esetben az API-k sebezhetőségét használták ki – gondoljunk csak a Salesforce.com, a T-Mobile, a Strava és az Egyesült Államok Postaszolgálatának esetére.\n\n## A hagyományos biztonsági megoldások nem nyújtanak megfelelő védelmet\n\nNapjainkban az API-támadások egyre összetettebbek, célzottabbak, amelyek könnyedén megkerülik a hagyományos védelmi rendszereket. Sajnos, a klasszikus webalkalmazás tűzfalak (WAF-ok), hitelesítő, tartalomszűrő illetve egyéb, alapszintű biztonsági eszközök NEM KÉPESEK az ilyen támadások észlelésére. A fejlett API-támadások csak célzott megoldásokkal akadályozhatók meg. Azok a vállalatok, amelyek nincsenek ezzel tisztában, hamis biztonságérzet mellett teszik kockára a központi rendszereiken tárolt adatokat.\n\n## Az API fejlesztők nem feltétlenül biztonság tudatosak\n\nA biztonság nem prioritás a legtöbb fejlesztési projektben: a fejlesztők a funkcionális specifikációra, a felhasználói élményre és a határidőkre koncentrálnak. Gyakran előfordul, hogy a biztonsági követelmények nincsenek is részletesen specifikálva. A biztonsági csapatoknak alig vagy egyáltalán nincs beleszólásuk az ilyen projektekbe. Ennek következtében a fejlesztők eszközkészlete és munkafolyamatai biztonsági szempontból nincsenek optimalizálva. A fejlesztők nem úgy gondolkodnak, mint a támadók. Mivel API sztenderdek nincsenek, ezért a biztonsággal sokszor csak 'best-effort' jelleggel foglalkoznak. Ez különlegesen sebezhetővé teszi a publikus API-kat, amely az üzletmenet számára kockázatokat, míg a rossz fiúk számára további lehetőségeket teremt.\n\n## A törvényi szabályozások biztonságos API-kommunikációt követelnek meg\n\nA PSD2 kötelezi a bankokat, hogy tegyék közvetlenül elérhetővé API-jaikat az online kereskedők és a külső fizetési szolgáltatók (TPP, fintech) számára. A GDPR közvetetten, de előírja a továbbított személyes adatok anonimizációját vagy pszeudo-anonimizációját. A PCI DSS kötelezi a pénzügyi szolgáltatókat, hogy a nyílt hozzáférésű hálózatokon titkosítsák a kártyatulajdonosi információkat, stb., stb... Az összes szabályozásnak egy közös, kulcsfontosságú követelménye van: a vállalatoknak gondoskodniuk kell az ügyféladatok biztonságáról azok tárolása és továbbítása során is. Ahhoz, hogy megfeleljenek ezeknek a feltételeknek, a szabályozott iparágaknak, mint például a pénzügyi, egészségügyi és állami szektornak, gondoskodniuk kell a nyilvános API-jaikon keresztül továbbított ügyféladatok védelméről.\n\n## Konklúzió\n\nÖsszegzésként elmondható, hogy számtalan API-alapú alkalmazás sebezhető. Napjainkra az ezeket a biztonsági réseket kihasználó támadások valódi fenyegetést jelentenek. Az API-támadások egyre összetettebbek és célzottabbak, és megkerülik a meglévő védelmi rendszereket. A nyilvános API-infrastruktúrát működtető szervezeteknek át kell értékelniük kockázati és megfelelőségi helyzetüket az API-k szempontjából. És itt nem csak a végfelhasználói vállalatokról van szó, az informatikai fejlesztőknek is gondolniuk kell az API-biztonság mélyebb szintű integrálására a projektjeikben. Az egyedi fejlesztésű alkalmazások biztonsági réseinek csökkentésével a hitelességüket és a jó hírüket is növelhetik.\n\n*A [Proxedo API Security](https://www.balasys.hu/hu/proxedo-api-security) egy speciális webes alkalmazás-tűzfal (WAF), amelyet az API-végpontok védelmére fejlesztettek ki. Egy rugalmas hálózatbiztonsági célmegoldás, amellyel szabályozhatja alkalmazásai adatforgalmát az API-támadások megelőzése érdekében. A Deep Packet Inspection (DPI) technológiának köszönhetően részletesen ellenőrizheti, titkosíthatja, és elemezheti az API forgalmát, mindezt kiegészítve egy szignatúra adatbázis-alapú védelemmel. Rugalmas architektúrájának köszönhetően vállalata kompromisszumok nélküli, egyedi API-biztonsági házirendet kényszeríthet ki. A Proxedo API Security kifejezetten az API-biztonságra összpontosít, így remekül kiegészíti a hagyományos WAF és API menedzsment eszközöket is.*\n","date":"February 2, 2021","id":"Blogposts_1","short_description":"A digitális átalakulás korában kiemelt szerepet kap az ügyfelek, a cégek és a partnerek közötti gyors kapcsolattartás és adatcsere.","isEnglish":false,"isHungarian":true,"slug":"miert-fontos-az-api-biztonsag","title":"Miért fontos az API-biztonság?"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/proxedo_api_use_case_v2_e78ad01b98.png"},"content":"*Today’s API attacks are increasingly complex, targeted, and easily bypass traditional security solutions. Even Web Application Firewalls (WAFs) and API management tools are unable to block these attacks as they are not optimized for deep inspection of API traffic. API security is not the main scope of these solutions, but a \"checkbox feature\" in many cases. Without targeted protection, you may be exposing your core systems data with a false sense of security. The following post highlights the key limitations of WAFs and API management tools and suggests a purpose-built complementary solution against API-specific threats.*\n\n## Challenge No.1.\n\n### Limitations of WAFs\n\nA web application firewall (WAF) filters, monitors, and blocks HTTP traffic to and from a web application. However, WAFs are unable to block targeted API attacks as they are not optimized for deep inspection of API traffic. WAF products are typically optimized for signature-based filtering of HTTP traffic. They are not suitable for controlling data flow embedded in API communication. They lack traffic validation, detailed logging and the ability to implement customized security policies. Enterprises using traditional WAFs should need a specific solution that explicitly addresses these limitations.\n\n## The Solution\n\n### API Security beyond WAF\n\n**Proxedo API Security (PAS) is a specific web application firewall exclusively for protecting API-endpoints.** It's a highly flexible network security solution that helps your enterprise gain control over the application communication to prevent API breaches. Based on our Deep Packet Inspection (DPI) technology, you can validate, encrypt and analyze API traffic in detail and implement a signature-based protection. Thanks to our flexible architecture, you can enforce custom security policies without compromise. PAS focuses exclusively on security by offering a killer combination of enforcement and insight of API traffic, supplemented by generic WAF functions. Proxedo API Security perfectly complements traditional WAF solutions.\n\n![blogpost.png](/blog/blogpost.png)\n\nThe following table summarizes the key differentiators of Proxedo API Security compared with traditional web application firewalls: \n\n| Web Application Firewalls  | Proxedo API Security  |\n|---|---|\n| Focus only on web application protection  | Focus on web application and B2B application integration protection  |\n| Inspection only on HTTP protocol  | Inspection on API layer  |\n| No DPI (Deep Packet Inspection)  | Advanced DPI  |\n| No API call validation  | API call validation  |\n| Limited logging capabilities  | Customizeable traffic- & security logging  |\n| No flexible policy configuration  | Flexible policy configuration  |\n| Pattern matching based on URL database (black list)  | Policy and rule implementation based on the protected service (\"white listing\")  |\n\n## Challenge 2.\n\n### Limitations of API management tools\n\nThe main scope of API management tools is creating, deploying, and managing APIs. Security is not the main scope of these tools. API management tools typically focus on:\n\n- API lifecycle management\n- API client authentication, authorization and account management\n- API traffic orchestration, optimization and load balancing and\n- Descriptors and documentation\n\n## The Solution\n\n### API Security beyond WAF\n\nProxedo API Security is NOT a management tool, but a dedicated solution with clear focus on security. In contrast to API management vendors where security is just a checkbox feature, PAS focuses exclusively on API endpoint protection by offering a killer combination of validation, transformation, encryption and insight of API traffic. From security standpoint, Proxedo API Security adds great value to API management solutions, as well. As an extra layer, PAS supports:\n\n- API traffic validation\n- Customizable API traffic encryption\n- Customizable security policies\n- In-depth, data-level logging and insight\n- Connection to authentication systems\n\n[Learn more about Proxedo API Security here. ](https://www.balasys.eu/en/proxedo-api-security/)\n\n","date":"October 29, 2020","id":"Blogposts_2","short_description":"A Proxedo API Security use case","isEnglish":true,"isHungarian":true,"slug":"complement-web-application-firewalls-and-api-management","title":"Complement web application firewalls and API management"},{"author":"Marosvári Gábor, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/wafpost_9aefa57025.png"},"content":"*Az elmúlt időszakban az intenzív fejlesztés és háttérmunka miatt kevesebb Zorp-pal kapcsolatos hírt közöltünk. Szeretnénk hangsúlyozni, hogy a Zorp Gateway fejlesztése ettől függetlenül folyamatos! Erőfeszítéseinknek köszönhetően a Balasys rugalmas, proxy alapú hálózatbiztonsági csomagja mostantól frissített architektúrával, megújult felhasználói felülettel és számos új funkcióval büszkélkedhet. Ebben a bejegyzésben szeretném összefoglalni azokat a legfontosabb új funkciókat, amelyek a 6.0 kiadás óta a termékbe kerültek.*\n\n## 1. TLS 1.3 támogatás\nA Zorp Gateway az egyik első olyan IT-biztonsági termék volt, amely támogatta a legújabb TLS 1.3 kriptográfiai protokollt. A piacon jelenleg elérhető legfejlettebb titkosítási szabvánnyal titkosíthatja a nem titkosított vagy régebbi (legacy) internetes protokollokat. A kommunikáció biztonsága tovább javítható az erős felhasználói hitelesítés megkövetelésével. E funkciókészlet révén a kevésbé biztonságos internetes infrastruktúrán keresztül is biztonságos webböngészést, levelezést vagy akár e-banking/e-kereskedelmi szolgáltatásokat valósíthat meg. Egy másik lehetséges felhasználási terület a felhőszolgáltatásokban tárolt adatok erős titkosítása.\n\n## 2. Webes alkalmazás tűzfal (WAF)\nAz Apache ModSecurity WAF-fal történő integráció révén a Zorp Gateway mostantól képes megvizsgálni és elemezni a titkosított és nem titkosított internetes forgalom tartalmát annak érdekében, hogy az megfelel-e a használt HTTP(S) szabványnak. A fejlett támadási vektorok felderítésén túl a webszerverek sebezhetőségeit vagy fejlesztési hibáit is képes elrejteni. Ez egy megbízható eszköz a szervezet nyilvános internetes szolgáltatásainak védelmére.\n\n![Picture1.png](/uploads/Picture1_8da093cc28.png)\n\n## 3. ICAP-támogatás\nA Zorp Gateway mostantól támogatja az Internet Content Adaptation Protocol (ICAP) protokollt. Az ICAP-támogatásnak köszönhetően a Zorp Gateway integrálható számos harmadik féltől származó biztonsági megoldással, például DLP-kkel, IDS/IPS-ekkel és antimalware eszközökkel, beleértve a multiscan motorokat és sandbox-technológiákat. A fenti integrációk titkosított csatornán keresztül is megvalósíthatók. \n\n![Zorp-IDS-IPS.png](/uploads/Zorp_IDS_IPS_d9dde3a359.png)\n\n## 4. Hosztnév-alapú szabályok\nSok weboldal (pl. facebook.com) nem rendelkezik fix IP-címmel, mégis ellenőrizni kell hozzájuk a hozzáférést. Előfordulhat az is, hogy bizonyos típusú titkosított forgalmat nem szabad ellenőrizni (adatvédelmi vagy egyéb okokból), mégis némi ellenőrzést azért szeretnénk ezen forgalmak felett is. Ilyen esetekben a hosztnév-alapú döntések segíthetnek: pusztán a hosztnév alapján ellenőrizheti az ilyen webhelyekhez való hozzáférést. Lényegében ez egy speciális URL-szűrési képesség, amely segít a szabályok felállításában kizárólag a domainnév információi alapján, az IP-cím vagy a kimenő forgalom tartalmának ismerete nélkül. Ezt a funkciót például a következő esetekben használhatja ki:\n \n- A nem kívánt webhelyekhez, alkalmazásokhoz vagy tartalmakhoz való hozzáférés megtagadása - pl. filmstreaming vagy felnőtteknek szóló webhelyek blokkolása.\n- Szelektív tartalomszűrés - pl. a Windows frissítési szolgáltatások vagy az internetes banki forgalom engedélyezése, de az összes többi tartalom vírusellenőrzése. \n- A titkosított forgalom terheléselosztása - pl. a sávszélesség-igényes YouTube-forgalom átirányítása a tartalék vonalra.\n\n## 5. Rate limiting \nA Zorp Gateway lehetőséget ad a hálózati kapcsolat sávszélességének korlátozására is. Ez a funkció különösen akkor jön jól, ha webhelyét (D)DOS-támadás éri, vagy ha a mindennapi forgalomban csúcsok jelentkeznek. A terméket úgy konfigurálhatja, hogy ilyen esetekben rangsorolja a kéréseket úgy, hogy a fontosabb tranzakciókat szolgálja ki először, míg a többiek számára korlátozza a sávszélességet.\n\n## 6. Fejlett protokollfelismerés\nA Zorp Gateway képes automatikusan felismerni bizonyos protokollokat és szolgáltatásokat, és az előre beállított kapcsolati szabályok alapján szelektíven kezelni ezeket. Jelenleg a támogatott protokollok és szolgáltatások a következők: HTTP, SSH, szervertanúsítvány és Server Name Indication (SNI).\n\n## 7. Űrlapalapú hitelesítés (Form-based authentication)\nA Zorp Gateway 7.0.5 támogatja az űrlapalapú hitelesítést a HTTP protokollban. A felhasználó számára egy szerkeszthető \"űrlap\" jeleníthető meg, amelyet ki kell töltenie és el kell küldenie, hogy bejelentkezzen egy adott webes alkalmazásba vagy szolgáltatásba. Ez akár a meglévő AD/LDAP-címtárral is integrálható. Az űrlapalapú hitelesítés egy platformfüggetlen és testre szabható megoldás a webalapú hitelesítési folyamat egységesítésére a vállalat, az ügyfelek és a partnerek körében.\n\nFolytatjuk a Zorp Gateway fejlesztését, hogy a hazai piacon jelenleg elérhető legjobban testre szabható, legmegbízhatóbb és leginkább erőforrás-hatékony hálózati biztonsági csomag legyen. Mostantól rendszeresen közzétesszük a fontosabb híreket a Balasysról és a Zorp termékcsaládról. Maradjanak velünk! \n\n*Tudjon meg többet a [https://www.balasys.hu/hu/zorp-gateway](https://www.balasys.hu/hu/zorp-gateway) oldalon.*\n","date":"March 18, 2020","id":"Blogposts_9","short_description":"Az elmúlt időszakban az intenzív fejlesztés és háttérmunka miatt kevesebb Zorp-pal kapcsolatos hírt közöltünk, de a Zorp Gateway fejlesztése ettől függetlenül folyamatos! ","isEnglish":false,"isHungarian":true,"slug":"ujdonsagok-a-balasys-zorp-gateway-7-0-5-ben","title":"Újdonságok a Balasys Zorp Gateway 7.0.5-ben"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/zorp_gpl_d4d67f38d9.jpg"},"content":"*The following post describes the benefits of Zorp GPL when used as an ingress controller in your Kubernetes environment. Kubernetes (K8s) is an open-source system for automating deployment, scaling and managing containerized applications.*\n\nZorp GPL has been developed for highly distributed networks and high security requirements. It provides advanced encryption, authentication and authorization features and actively mitigates attacks against the cloud infrastructure. As part of the numerous tools delivered by Kubernetes to aid you in creating scalable applications, Zorp GPL serves as a drop-in cloud security solution for your K8s projects. \n\n![zorp-gpl.jpg](/blog/zorp-gpl.jpg)\n\n*Zorp GPL acts as an advanced ingress controller and load balancer – based on the pre-configured security policy, it routes the incoming HTTP(s) traffic to the appropriate Docker container. You can configure and enforce security policies not just for HTTP but also for FTP and SMTP connections. Zorp’s protection is provided at application-level through perimeter defense technology that satisfies the highest security needs.*\n\nZorp GPL is an open source, cloud-based firewall service, available free of charge for your Kubernetes environment. Download it here: [https://github.com/Balasys/zorp-ingress-controller](https://github.com/Balasys/zorp-ingress-controller)\n","date":"March 17, 2020","id":"Blogposts_4","short_description":"The benefits of Zorp GPL when used as an ingress controller in Kubernetes","isEnglish":true,"isHungarian":true,"slug":"zorp-gpl-an-open-source-cloud-based-firewall-for-kubernetes","title":"Zorp GPL – an open source, cloud-based firewall for Kubernetes"},{"author":"Gábor Marosvári, Product marketing lead, Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/api_security_post_e041b9c044.png"},"content":"\n\n*In the era of digital transformation, there is a strong focus on interconnectivity and data exchange between customers, businesses and partners. This has resulted in a boom in public-facing APIs (Application Programming Interface), an HTTP-based application integration protocol which exposes application data to connected parties, devices and services. Today, to enable seamless machine-to-machine communication, APIs connect tens of thousands of web and cloud applications, microservices, mobile and IoT devices. And their number is skyrocketing.*\n\nAPIs don’t expose just Facebook messages anymore, but an enormous amount of sensitive information: user IDs, financial data and corporate secrets are also transferred via these interfaces. APIs have become direct shortcuts to the heart of your organization. As a result, the proliferation of API infrastructures has brought with it huge security challenges. This post summarizes the major concerns around API-communication security and introduces a potential solution.\n\n![api-security-post.png](/blog/api-security-post.png)\n\n## Hackers shift their interest to APIs\n\nThe amount of sensitive data exposed via APIs is increasing significantly, making APIs a primary target for attackers. They’ve started to look for vulnerable, broken APIs to find ways to the back-end systems that store sensitive data. And they are becoming increasingly successful. Many recent huge data breaches have leveraged APIs – just think of the [Salesforce.com](https://www.zdnet.com/article/salesforce-warns-customers-of-data-leak-caused-by-api-error/) , [the US Post](https://www.bankinfosecurity.com/us-postal-service-plugs-api-flaw-one-year-later-a-11722) , [T-Mobile](https://www.forbes.com/sites/leemathews/2018/08/24/t-mobile-hackers-swipe-data-on-2-million-subscribers/?sh=4aa8eb797a52) and [Strava](https://businessinsights.bitdefender.com/2018-sees-api-breaches-surge-with-no-relief-in-sight) incidents.\n\n## Traditional security solutions are insufficient\n\nToday’s API attacks are increasingly complex, targeted and easily bypass traditional security solutions. These attacks CANNOT be detected by signature-based web application firewalls (WAFs), authentication or other baseline security tools. Advanced API attacks can only be prevented by targeted solutions. Without this knowledge in mind, businesses may expose their core systems data with a false sense of security.\n\n## API developers work without focusing on security\n\nSecurity is not a priority for many application development projects: they focus on the functional specification, user experience and deadlines. Often, security requirements are not specified in detail in these projects. Security teams have either no or limited influence on security during these projects. As a result, the developers’ toolset and workflow processes are not security-optimized. They don’t think like attackers. They deal with security just on a best-effort basis. This practice leads to unique vulnerabilities in public-facing APIs, which in turn creates risk for the business and opportunities for the bad guys.\n\n## Regulations require secure API communication\n\nPSD2 requires banks to open their APIs directly to retailers and third-party payment providers (TPP or fintech). GDPR indirectly requires anonymization or pseudo anonymization of personal data in transit. The PCI DSS requires financial providers to encrypt transmission of cardholder data via public networks… All these regulations have one key requirement in common: they require companies to protect customers’ data at rest and also in transit. To meet these criteria, regulated industries like finance or public services must start thinking about how to secure the sensitive data flow via their public-facing APIs.\n\nTo sum up, many API applications are vulnerable. And breaches leveraging these vulnerabilities are genuine threats today. API attacks are increasingly complex, targeted and bypass the existing defense lines. This means that organizations operating public API-infrastructures should re-evaluate their risk and compliance posture from an API perspective. Not just end-user companies, but also IT developers should consider deploying/integrating a greater level of API security in their projects. By reducing security gaps in custom-developed applications, they can also increase their credibility and reputation.\n\n*The Prodexo API Security is a highly flexible API security gateway which helps enterprises gain control over their API traffic. With Prodexo API Security, you can enforce, transform, encrypt and analyze the API traffic to prevent API breaches. Thanks to the flexible architecture, your organization can implement custom API security policies without compromise. Learn more here: [https://www.balasys.eu/en/proxedo-api-security](https://www.balasys.eu/en/proxedo-api-security)*","date":"March 17, 2020","id":"Blogposts_5","short_description":"Major concerns around the security of API-traffic and introduction of a potential solution. ","isEnglish":true,"isHungarian":false,"slug":"why-do-you-need-api-security","title":"Why do you need API security?"},{"author":"Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/how_to_secure_your_API_communication_v2_fe91ef865b.png"},"content":"*In the life of any business, it is essential to provide secure and reliable services to their customers and partners in order to keep their financial, personal or other confidential data safe. With the ever-growing number of IoT and microservice providers and our heightened online security awareness, it is vital to make public-facing APIs (Application Programming Interfaces) more secure than ever before. But how can a company or a developer team make sure their API environment is hackerproof? Let’s dive into the details!*\n\n## How does an API work?\n\nIn order to understand why API security is so important today, we need to understand how APIs work, and what they are good for. So, let’s start at the beginning.\n\nMaybe it is easiest to explain how an API works if we use the analogy of watching TV. Imagine that you are at home, relaxing and watching TV, browsing the programs on each channel. You are most probably using a remote control to switch between these channels. An API behaves like this remote control. It shows you different buttons (endpoints), whose capabilities you are aware of, and by pushing them the remote makes the TV do what you intended. In a nutshell, the remote makes the actions of the TV accessible to you, and this is exactly what an API does. The users don’t understand how the API works and don’t need to understand it – they simply click on a button they want, and the software does the rest.\n\nMaybe it is easiest to explain how an API works if we use the analogy of watching TV. Imagine that you are at home, relaxing and watching TV, browsing the programs on each channel. You are most probably using a remote control to switch between these channels. An API behaves like this remote control. It shows you different buttons (endpoints), whose capabilities you are aware of, and by pushing them the remote makes the TV do what you intended. In a nutshell, the remote makes the actions of the TV accessible to you, and this is exactly what an API does. The users don’t understand how the API works and don’t need to understand it – they simply click on a button they want, and the software does the rest.\n\n![how-to-secure-your-API-communication.png](/blog/how-to-secure-your-API-communication.png)\n\n## What are API communication channels and what are they good for?\n\nAPIs use communication channels to collect certain data from the users in exchange for the functionality they offer as a service. There are various kinds of communication channels. For example, they could be a pop-up form, login platform, online payment service, integrated live chat, push notification, CRM system, social media share buttons or a custom-made monthly report. With the use of these channels and the information provided, the company can make sure that they offer personalized customer experience, support and developments. These channels are essential for the smooth operation and maintenance of the enterprise, because communication channels help them to collect payment for the service and market their solutions.\n\n## Why are API channels critical from a data security point of view?\n\nAs you can see from the above examples, API channels are used to transfer all kinds of information between the end-user and the company servers. These range from confidential contracts through credit card information to personal data such as names and email addresses. If these get into the hands of malicious actors who take advantage of a vulnerability, the acquired data can be used for their own purposes, such as initiating a money transfer, making online purchases or getting involved in illegal online activities in someone else’s name. If a data breach like this occurs, the hacked company can lose a significant segment of its customer base, not to mention the rapid collapse of its reputation and a potentially heavy financial penalty.\n\n## How can you make sure what type of data is passing through API channels?\n\nIn order to make sure that all data flowing through the API is correct and free from any malware, enterprises need to equip their API infrastructures with an API security gateway that protects not only the interests of the company but also the privacy of its customers. API gateways are empowered with many advanced security features that aim to hinder hackers from accessing managed data and ensure only proper requests can reach the server and database. Which functions can help organizations control information passing through the API?\n\n- Request and content validation\n- Authentication and authorization\n- Traffic encryption\n- Content filtering (anti-malware)\n- Traffic manipulation and transformation\n\n## How can we detect malicious activity in API traffic?\n\nPreventing hackers from accessing confidential data and validating transferred content is just the first step towards reaching the adequate level of API security. What if you have done everything and some tricky malware or a malicious user still bypasses your first line of defense? With the following security features and measures, you can still detect malicious activity in API traffic before it does any harm:\n\n- Properly defined API-security policies\n- Security and audit logging, focusing on access requests and transactions\n- Monitoring encrypted HTTPs channels\n- Data modification\n\nAll the above-mentioned security features work in close cooperation with each other to prevent data breaches originated from phishing, XSS (Cross-site Scripting), or (D)DOS attacks, by monitoring, validating and analyzing data that is moving back and forth through the API.\n\n## Conclusion\n\nAll things considered, today no enterprise that handles personal, governmental or any other type of confidential data can neglect the topic of API security, because even the smallest level of ignorance could end up with them paying the consequences, big time. It is always better to be safe than sorry, which is why we advise organizations to consider API security in the first phase of their software development projects.\n\n*Due to their advanced security features such as authentication, log analysis, encryption, content filtering, and validation, API security gateways are perfect tools for ensuring data security and detecting malicious activity at an early stage. If you also agree that exposing yourself to API security issues is not a risk worth taking, try Balasys' Proxedo API Security, which empowers you with its first-class solutions to make your APIs impenetrable. Learn more here: [https://www.balasys.eu/en/proxedo-api-security](https://www.balasys.eu/en/proxedo-api-security)*","date":"February 6, 2020","id":"Blogposts_6","short_description":"In order to understand why API security is so important today, we need to understand how APIs work, and what they are good for. ","isEnglish":true,"isHungarian":true,"slug":"how-to-secure-your-api-communication","title":"How to secure your API communication"}]}},"pageContext":{"locale":"en"}},
    "staticQueryHashes": ["3233329270","3621970722","521397250","585144119"]}