Latest Posts

Lunch & Learn: Compliance and Cybersecurity for Financial Institutions

When it comes to cybersecurity, banking is one of the most highly-regulated industries, with multiple checks and failsafe steps put in place to ensure the highest possible level of protection. And while industry as well as government regulations include extensive, rigorous assessments, compliance alone does not suffice. Financial institutions simply must take the extra steps beyond compliance to ensure that their network and clients’ information are protected from cyber threats.

On February 22nd, Network Box USA and ReliableIT hosted a Lunch & Learn for financial institutions at Maggiano’s Little Italy in Houston. This casual gathering was aimed at discussing compliance and cybersecurity. Attendees enjoyed a family-style Italian meal, as Nikki Almazan, Banking Compliance Expert from ReliableIT, talked at length about the threat landscape for banks and credit unions.  She also touched on CAT, the Cybersecurity Assessment Tool, put forth by the FFIEC.

After the presentation, Pierluigi Stella, CTO of Network Box USA, opened the floor for a roundtable discussion that included hot topics such as ransomware and web application security. He also, of course, circled back to the issue of the hour, compliance.

“Compliance and security go hand-in-hand. Compliance regulations are created to help and, in some ways force, companies to adhere to standards that, on a whole, will contribute to make them more secure. Or, at least, forces them to think about security. Although being compliant does not necessarily make a company secure, compliance is certainly a vital step towards security,” said Stella.

Network Box USA thanks all who attended, and would like to extend our appreciation to the team from ReliableIT.

Network Box USA named in CIO Review’s 20 Most Promising DDoS Solution Providers for 2016

CIO Review – DDoS Special

The corporate world is constantly getting smarter by leveraging the latest internet technology advancements. Information sharing has over the years witnessed a gradual displacement of paper with digital becoming the dominant and favored medium. While, undeniably, this transition has boosted communications within and between enterprises, it has also made it a lot easier for hackers to breach an enterprise and disrupt these communications, curtailing business operations. Attackers infiltrate an enterprise’s Domain Name System (DNS)—freezing the network or infecting the DNS with botnets.

Such infiltrations, known as Distributed Denial of Service (DDoS) attacks, make business operations arduous by temporarily suspending services and making them unavailable for customers. To purge these challenges, it becomes important to defend an enterprise’s DNS servers and networks from DDoS onslaughts. Preventing these infiltrations requires purpose-built network architecture which can detect and subdue the often deceptive and wildly complex DDoS attacks.

In the current IT market sphere there are many DDoS solution providers offering secured services with a myriad of features and functionalities—Software-as-a-Service (SaaS), traffic control, and firewall protection to fight DDoS attacks in different layers. Presently there are vendors providing solutions that can curb attacks of up to 300 Gbps, and above. CIOReview helps enterprise CIOs looking for key technologies related to DDoS navigate this landscape by presenting a list of ‘20 Most Promising DDoS Solution Providers 2016.’

Network Box USA – Multilayered Threat Protection

In recent years, web applications have been subjected to DDoS attacks more than any other type of network or application, which Pierluigi Stella, CTO of Network Box USA (NWB) points-out to be the challenging task for organizations to address, because it requires a coordinated effort between client, service provider and the ISP. Today, many companies offer DDoS protection by simply moving the client’s internet presence onto a very large cloud solution—capable of absorbing almost any size of attack. “However this solution is not optimal for all users, as they cannot afford to pay a huge sum and requires providing DDoS protection in every way the client can implement it, while remaining affordable,” says Stella.

Unlike many Web Application Firewall systems on the market, NWB’s suite of security solutions provides a wide range of capabilities to allow for the mitigation of DDoS attacks. Befitting its name, the firm’s Anti-DDoS WAF+ system allows companies and organizations to implement effective Anti-DDoS technology on an affordable basis. As a managed security services provider, NWB combats increasing danger posed by security breaches, virus attacks and similar threats arising from widespread use of the Internet. The Network Box networking stack consists of many layers of protection: layer 3—protocol enforcement, including connection rate, data transfer volume and handling connection slowness; and a wide range of application protection—layer 7, where URL pattern, user agent and request header are taken into account.

The Anti-DDoS WAF+ uses behavioral analysis, traffic signatures, rate limiting, and other techniques to identify malicious traffic per source-address. “Dynamic blacklisting and intelligent analysis recognize similar patterns when the attacking IP addresses change, and can automatically keep up with the attack to continue blacklisting the new sources, dropping their connections before they cause damage,” delineates Stella. “NWB offers these capabilities onsite and in the cloud.”

NWB’s Anti-DDoS system’s protection starts with the intelligence gathered from over 70 global security sources, including Microsoft’s Active Protections Program and Kaspersky Labs. Real-time automated fingerprinting is then utilized, to slow down DDoS attacks by a factor of about a millisecond automated response. Most importantly, the firm’s managed services suite is equipped with 16 Security Operations Centers (SOC) as well as a Security Response Center (SRC) to increase the security posture of the clients, quickly and efficiently. “The SRC is where the intelligence analysis happens and security analysts spend their entire time learning ways to create real-time protection—be it in the form of new signatures, or libraries, heuristics, or codes,” points-out Stella.

According to Stella, “Speed and security are of the essence when fighting against cyber threats, and we make it a point of delivering protection—unbelievably in short and true real-time.” Network Box USA’s Managed Cloud Email Security provides robust, multilayered email threat protection and it is cost-efficient as it is sold as a service, hosted in the cloud and completely managed. With its patented PUSH technology, the firm ensures that customers’ solutions are protected with the latest security updates in less than 45 seconds upon availability. In addition, Network Box’s Z-Scan, a true real-time zero-day anti-malware engine, reacts by creating fingerprints, which are available to all NWBs globally within 3 seconds, as they are made available through NWB global private cloud.

Forging ahead, the firm is planning to offer its services via AWS, Google and Azure and intends to set up more SOCs. “We are also aiming to bring in a new service—MCPROXY—for clients who desire the same quality of protection that NWB offers, but are not willing to pay the cost of a full, dedicated, managed solution. MCPROXY will be a low cost, cloud based shared proxy offering, where, although the configuration capabilities will be limited, clients will still get the full
protection of the NWB services, including HTTP and HTTPS AV scanning and web filtering. This system is currently under test,” concludes Stella.

Spear Phishing, Conclusion

written by Pierluigi Stella

In this concluding post on the topic of Spear Phishing (read the first one here), allow me to share something which happened to one of our clients last week.

The sender “appeared” to be the CEO; but that was only the “From:”.  The actual sender in the envelope was – a fake sender.  The originating IP address was; this IP is in Scottsdale, AZ, and corresponds to DNS name  The server connected to our device with a EHLO message of

Our client’s domain is none of this.  However, the From: and To: fields appeared to be both from someone @ our client’s domain.

The first reaction one could have would be to apply SPF control.  However, SPF is applied to the envelope, not to the body headers.  The envelope shows as the sending domain, and as the EHLO domain.  Upon checking the SPF record of the server, we note that the sending IP is included.  So SPF did not fail.  The email, on the surface, looked legitimate.  Besides, SPF isn’t mandatory.  In this case, the server had one and it matched.  In many other cases we’ve seen, there simply wasn’t an SPF record to match.  We cannot discard emails only based on that fact, because SPF isn’t required.  If it exists, it must be respected; but since it isn’t a requirement, if a domain has no SPF record, we still need to accept emails from that domain.

email security

In case it isn’t clear, there’s a specific reason why the envelope sender doesn’t match the apparent sender (From:).  Your domain _could_ have an SPF record; in which case, it’d be extremely easy for us to catch that email as a spoof, because it’d be originating from an IP address that isn’t authorized.  And if, by any chance, it did originate from an IP that you’ve authorized in your SPF record, then you’ve a much larger problem because one of your servers has been compromised ☺

So, how do you block such emails?  Actually the answer is simpler than I’ve made it look so far.  We can easily create a rule that says “if the header:from is from someone at my domain, the recipient is to someone at my domain, but the sender is not, block that email”.

However, we cannot apply such a sweeping rule without thorough consideration.  You may have hired a marketing firm to send emails on your behalf, including emails to your own employees/colleagues, and generally, they make it a habit of using a From: that makes them appear as though they’re coming from your company.  For example, I’ve seen emails from doing just this.  You set up an invitation for your entire company, specify your own email address, and  click GO.  They’ll generate an email to everyone on your list (your colleagues), the header:From will contain _your_ email address; but the envelope sender will be something random

email rules

To avoid catching such legitimate emails in the sweeping net of the rule above, we create a list of email addresses and domains that _you_ want to authorize to send such ‘spoof looking’ emails.  So, say I were to do this for our company, the rule would look something like this:-

deny header:from endswith recipient endswith sender notinacl authorized-spooffers.

I know, it sounds/looks/reads strange.  But it’s a very effective way to solve the issue of spear phishing that’s currently plaguing many companies.  And the only input we need from you is that list of domains or companies you want to allow in the rule above.

Makes sense?

Has your company experienced Spear Phishing?

Or any other form of spam?

Spear Phishing, Part 1

written by Pierluigi Stella

One of the dangerous issues we currently face with spam emails is that of spear phishing – a type of phishing spam email targeted at the recipient.  While most spam deploy a shotgun approach (send billions of emails and see what sticks), spear phishing attacks are specifically aimed the recipient, requiring hackers to do homework on the targeted victim.  It is by no means random.  If their efforts are to be handsomely rewarded, they must target Executive and C levels, whereby a click on the wrong email can inflict serious damage.  These emails are usually made to appear as though they are coming from one C level, to either another C level or someone else with authority to act upon the request.

Most of our clients are financial institutions (banks and CUs), and as such, a frequent phishing attempt we see in this particular sector is an email appearing to originate from the CEO.  The request likely to be to execute a wire transfer, with the intended target being the CFO, or the person in the bank who oversees such wires.

To be convincing, hackers need to emulate as much of the CEO as possible which, at first glance, may seem a daunting task.  Unfortunately, given how we are all far too eager to share as much of ourselves as possible these days, through various social media platforms, it isn’t as impossible a task as it might appear. Hackers can quickly find out the name of the CEO, they know the address of the business and the main phone number; thus crafting a false signature isn’t all that difficult.  If the recipient has never received an email from the CEO before, he/she may well fall into the trap.

The second step is to find out who’s doing the wires.   That’s why the CFO might be the target here; because he has the authority to forward that email and ask for the wire to be executed.  However, we’ve also seen such emails directly targeting the employee who can run the wire.  In such instances, it means hackers have invested a little more time researching the company, perhaps through connections on Linkedin, who knows.  However they went about it, they now have the information they need, and placed a bullseye on that person.

Phishing Target

To understand how this could be technically possible, we first need to understand how email works, and what the SMTP protocol specifies and doesn’t specify (SMTP stands for Simple Mail Transfer Protocol and is the protocol used on the internet to send emails).  When SMTP was devised about 40 years ago, security wasn’t at all a concern.  Therefore, the creators of the protocol simply set out to model electronic communications in the image of physical mail.   When we write a letter, we have an envelope and a page where we compose the ‘body’ of our letter.  On the envelope, we write the name of the recipient, with the actual address we want it to go to.  We then pen our own name and address as the sender, so if the letter cannot be delivered, it is returned to us.

On the inside, however, we do not replicate all this.  Depending on the person to whom we’re writing, we may say “Dear Larry”, or “Hello son”, or something to that effect.  When we’re done, we end by signing the letter.  NOTHING says we _have_ to use our name.  We could be signing “Dad”; or “Pierluigi”, or use a nickname.

The SMTP protocol accounts for this and allows it in electronic format.  An email is comprised of 2 parts – the envelope and the body.  Users who never deal with email scanning, never see the envelope. Your email server behaves like JARVIS, opens the “letter” for you, discards the envelope.  So you, as a user, most likely are unawares this part of the email even exists.  I personally know I didn’t, that is, before I started dealing with spam and malware.

What you receive in your inbox is what we call the body of the email, which is the electronic equivalent of the actual physical letter of old times.  The body is, in turn, divided into 3 areas:-

  • Headers
  • Actual body
  • Attachments

We all know what attachments are.  We can easily understand which part is the ‘body’.  The headers contain a few, well specified, fields, the following being relevant to our current discussion:-

  • From:
  • To:
  • Subject:
  • Reply-to:


The From:, To:, and Subject: are those that Outlook shows you at the top of the email.  NONE of these fields is mandatory.  The reason why your email server sent that email to _you_ and not to someone else is because of what was written in the envelope; and not because of the To: field in the headers of the body.

This also means that these fields can be entirely different from those in the envelope.  And that’s where the phishing trick comes into play.  You as a user only see the From: and To:.  Therefore, if I’m a hacker, I can write the following into the email:-

To: (Luca Maestri is the CFO of Apple)

If Mr Maestri isn’t careful, he’ll think the email originates from Mr.Cook and will execute the order.  However, if we analyze the envelope logged into the server, we will likely find:-

  • The originating IP of the email does not belong to Apple
  • The server sending the email (identified by something called “EHLO) isn’t Apple’s
  • The sender in the envelope may or may not say, and most likely it does not

In our second and concluding part on Friday, we’ll share how one of our clients experienced Spear Phishing directly, and we went about to resolve the issue.


The Ransomware Epidemic: Why It’s Spreading and What You Can Do

If it hasn’t already been dubbed “The Year of Ransomware,” 2016 is well on its way to earning that title. Even though ransomware has been around since 1989 (starting with the AIDS Trojan), we’ve seen a spike in the number of incidents over the past couple years that has left us wondering:

Why ransomware? Why now?

While there are several factors contributing to the increase in ransomware activity, the driving force is more than likely the fact that ransomware is fast money – a short-term ROI. With ransomware, cybercriminals don’t have to worry about handling personal information and/or trying to sell that information on the black market. That comes as a secondary benefit once they’ve infected a machine. If they so choose, cybercriminals could easily walk away with just the ransom and no additional information. After all, according to a recent study, 40% of companies are willing to pay the ransom to decrypt their files and/or regain access to their machines (e.g. workstations).1

The introduction of crypto-currency (as in Bitcoin) has been attributed as a key catalyst to this growing epidemic. While traceable, crypto-currency is an easy, verifiable way for cybercriminals to get paid. Another contributing factor may simply be the fact that the size of the cyber landscape itself is significantly larger than it was in 1989 (when the AIDS Trojan was released).  To put it into perspective, over the course of a decade, the number of Internet users has increased by over 825%.2 That percentage excludes the number of devices (estimated at an average of 3 per person).3 In other words, the pool of targets has expanded (or widened) and, therefore, more opportunities abound for cybercrime.

What can I do?

First, it’s important to understand how ransomware spreads. The most common way it’s delivered is via phishing emails, followed by drive-by downloads, and then social media (i.e., a malicious link on Facebook). We’ve also seen instances of ransomware in malvertising campaigns. Cybercriminals are finding any and every opportunity to finagle their way into your network.

stop ransomwareSince delivery varies, there’s no single technique by which to stop ransomware in its entirety. Rather, it’s a collective effort between you, your employees, your vendors, and your cybersecurity solution.

In its simplest form – ransomware protection involves going back to cybersecurity basics:

Backup your data. At the very least, backing up your data will delay the impact after a ransomware attack. One of the costliest parts of cybercrime is its effect on business operations. Simply put, downtime is money lost.

Keep your systems up-to-date. This may seem like an obvious step, but it’s too often neglected, much like backing up data. The rate of threat generation (including ransomware) is uncanny and kind of scary. Keeping your systems updated ensures you have the latest protection in a threat landscape that’s constantly evolving.

Educate your employees. Often times, humans are pointed out as the weakest link in a cybersecurity chain. The reality is that they’re also your best defense. Ideally, ransomware is stopped before your employees even encounter it, which is why keeping your systems up-to-date is so important. However, in the event it does reach your employees, you want to be sure they don’t blindly accept enabling macros in a Word document, for example. Ultimately, educating your employees strengthens your security posture, as they become both your first and last line of defense.

Like crime in the physical world, cybercrime isn’t going anywhere, anytime soon. It’s a real threat with real repercussions.

What do you think is the driving force behind the increased ransomware activity? What other steps can companies take to stop ransomware? Let us know in the comments section below.


Why You Need a WAF – Conclusion

Over the past two editions, we outlined how vital it is to provide a robust security posture for one’s web server and the various options currently available.  In today’s concluding installment, we take a long, hard look at applications.

For instance, that application you’re currently using?  More than likely, it was not developed with security in mind.  No matter how much we discuss the topic and we talk about security driven application development, how many people and companies really even know how to do that?  How many developers test their applications from a security stand point?

And what if the application in question is old, a legacy development that was written 10 years ago?  Developers have moved on, documentation is scarce, if present at all, and yet the application plays a vital in your company’s business.

Updating the tools it relies upon isn’t even a question – the application will break.  Fixing the applications issues may well be even harder and often unfeasible.  The entire construct is a vulnerability disaster waiting to happen.  This is likely the most important example of where a WAF can be very useful.

A WAF will have a configurable layer where a business owner, or vendor can create specific signatures.  Therefore, instead of breaking the application, or living with one that is vulnerable and can expose confidential data, a WAF allows for the creation of customized protection, if you like, dedicated signatures tailored to very specific applications.  This allows organizations to achieve strong protection for their web applications without the need to alter functionalities, and without having to fuss over updating them in a rush.

Note that we are not advocating running that old COBOL application for the next 40 years.  And yes, sooner rather than later, we’d be better off scraping everything and rewriting applications with more advanced tools.  But the adoption of a WAF ensures that process to be just that – a process – instead of a frenzied decision dictated by the need to cover up security holes.

We hope that you’ve found this series (parts 1 and 2) on why you need a Web Application Firewall (or WAF) informative and useful.  Today’s threat landscape being this dynamic and fast-paced, organisations that fail to adequately arm themselves do so at great (financial and operational) risk.

Why You Need A WAF – Part 2

written by Pierluigi Stella, CTO of Network Box USA, Inc.

Previously, we touched on the critical value of protecting one’s web server, and the various way to do just that such as the setting up of a DMZ or the creation of an IPS.  We also introduced the fact that while a good idea, establishing an IPS in line with firewall as a means to intercept malicious traffic, was limiting.

As explained, an IPS cannot be effective against all potential application vulnerabilities.  Typically, an IPS ends up producing too many false positives, which in turn yield two possible reactions – either (1) it delays application response time and incorrectly interferes with the application; or (2)  it allows attacks as normal behavior in an attempt to reduce false positives.

An IPS looks at signatures and anomalies; a WAF looks at behavior and logic, analyzes traffic in both directions, looks at what is being requested, and what is being returned.

A Web Application Firewall’s main task is to protect web applications by inspecting the semantics of the flowing traffic and also inspecting HTTP/HTTPS for typical attacks at layer 7 such as SQL Injections, Buffer Overflow, Cross Site Scripting (XSS), File Inclusion, Cookie Poisoning, Schema Poisoning, Defacements, etc. To obtain a better understanding of the topic, a good source of information is found at this link.

OWASP is an open software security community collecting, among other things, the list of top attacks against web servers.  Any WAF on the market today will have to at least protect web applications and servers from the OWASP top 10.

Another aspect of using a WAF is called SSL offloading.  The internet is headed towards complete encryption. Increasingly, websites are using HTTPS, even when there is no confidential data to be protected.  If the website runs an application that requires confidential data to be entered, such as your online banking portal, the choice of HTTPS is obvious.  But there are plenty of examples of sites that are using HTTPS even though in principal they wouldn’t need to, because there is no private data to be protected.

Soon after the NSA scandal of 2014, chose to use HTTPS for all their pages.  Yahoo! has done the same.  And the examples are countless.  Encryption is adopted not just to hide searches, but to also guarantee the authenticity of a website.  Too many attacks are conducted by spoofing the looks of other websites, and the mechanism of private/public key/cert inherent to the HTTPS protocol is likely the last bastion against a widespread diffusion of such attacks.

For instance, when you go to, the certificate on that website (published and guaranteed by a certificate authority) tells your browser that you have indeed reached the intended site, and not some hacked, spoofed site that might try to collect information to, in turn, conduct an attack against you.

What does this really mean for one’s webserver?

If the server capacity was designed for HTTP and suddenly every single transaction is encrypted, the CPU load can become such that the server itself may not be able to handle it.  One feature where a WAF can help is HTTPS offloading – the certificates are placed on the WAF, the encrypted connection is terminated on the WAF.  Between this and your servers, the traffic does not necessarily need to be encrypted, thus “offloading” the function to the WAF.  This allows control over which version of TLS to use.  That said, given that every version of SSL has now been compromised, so in reality, no one should really be using that for their HTTPS protocol.  Yet we still see many websites that have not been updated and corrected, likely because the software version cannot be updated (for the reasons explained earlier).  The WAF can easily enforce the use of the appropriate TLS version, without the need to touch anything at all on the web server.

Because the WAF decouples the traffic between web server and internet, and the browsers are no longer connecting directly to the webserver, a WAF is an inbound proxy. Once we consider this, we see how it is possible to deploy other technologies commonly applied to outbound proxies to a WAF, such as AV and access control.  Applying AV rules to an inbound proxy may sound like a stretch because of possible performance limitations, and there are certainly issues with this; but it is vital to remember that in this case, we are not protecting a workstation.

We are protecting a very specific technology; so the applied AV can be limited to only signatures and heuristics that are relevant to a web server; there is really no need to run 11 million signatures to protect a web server.  And this can make running an AV more plausible.

At this juncture, it is also worth mentioning what WAFs do not do.

A WAF will not enforce access control in the traditional meaning of the term. Do not be confused by the term “firewall” present in the name of this technology.  A WAF only protects the server farm behind it, adopting signature based or anomaly detection algorithms but, unlike a network IPS, it will focus only on the HTTP and HTTPS protocols.  A WAF is a layer 7 technology, not layer 3.

Some Web Application Firewalls will also provide layer 7 protection against DDoS attacks, although most vendors separate the 2 types of protection, offering specific DDoS protection as a different service or appliance.  However, since this whitepaper pertains to WAF, we will not dwell on the details of DDoS attacks against web servers and why protection against such attacks is equally necessary.

Gartner’s magic quadrant for WAFs for 2014 says:

  • Protect web applications against hackers’ attacks, to monitor access to the web applications, and to collect access logs for compliance/auditing and analytics
  • Primary WAF benefit: providing protection for custom web applications that would otherwise go unprotected by other technologies that guard only against known exploits and prevent vulnerabilities in off-the-shelf web application software
  • WAF technology
    • Maximizes the detection and catch rate for known and unknown threats
    • Minimizes false alerts (false positives) and adapts to continually evolving web applications
    • Ensures broader adoption through ease of use and minimal performance impact

There is another aspect to WAF technology that must not be underestimated.   A web server runs 2 ‘applications’ – the web server itself (be it Apache or IIS or something else) and the user application (what you see when you go to that website).  And in between, there are the tools used to develop the user application itself.  These could be PHP, wordpress templates, java, ASP, you name it.

Each of these layers can have vulnerabilities.  Apache has its own and plenty of them; IIS does as well.  But these are often known, announced, patched and therefore, made irrelevant after a while.  Aside from that, once they are known, it is often possible to create IPS signatures that can protect the web server itself.

The real issues, the ones that can cost an organization its entire database, are those caused by the user level application and tools used to develop it.  Whether it is an off-the-shelf product or one developed in-house (which is most often the case), software invariably has errors, which leads to vulnerabilities.  It is not a matter of if, but how many, and how exploitable.

For example, PHP and Java have vulnerabilities.  But these aren’t tools you can always update as this (act) could break the actual application.  As such, these tools are often not updated, vulnerabilities are not patched, and they cause the application to be, well, laid bare and open to attacks.

Stay tuned for our third and final installment wherein we discuss the inherent security pitfalls in the applications we use.