Calculating Cyber Risk

Posted on by

Calculating cyber risk is at best an imperfect science. There are a number of factors that need to be calculated to determine risk, and the accuracy and completeness of each of these factors determine the overall accuracy of your risk determination.

There are two different types of risk assessments commonly used: qualitative risk assessment and quantitative risk assessment. A qualitative risk assessment does not try to assign a specific dollar amount or number value to the possibility of occurrence, impact or risk rating. Rather, these factors are expressed as severity ratings such as high, medium or low (or very high, high, medium, low and very low if you want to be more granular).

For whatever cyber asset you are assessing, you begin with determining threats to the asset paired with vulnerabilities that could be exploited by attackers to adversely affect that asset. These are called threat / vulnerability pairs. For each threat / vulnerability pair, you then determine the possibility that that threat may be realized (likelihood determination) coupled with the probable impact to the asset / organization if the threat is realized. You then subtract from this calculation the effectiveness of the security controls you have in place to prevent the threat actor from exploiting the vulnerability.

You can express this as a formula such as: (threat / vulnerability) x possibility of occurrence x impact – control effectiveness = risk (or residual risk). Although this is expressed mathematically, it should be understood that this is really a mind model rather than an actual quantifiable formula when performing qualitative risk assessment.

The same factors are also in play in a quantitative risk assessment. However, in quantitative risk assessment you try to assign actual numbers and dollar amounts to some factors. In other words, you might determine that the possibility of occurrence is 50% for a given period of time and that the impact of an occurrence will cost you $150, 000.

Although quantitative risk assessments give you harder data, they are best used for individual processes, applications or systems. Quantitative risk assessments are very hard to perform for complex systems such as are found in an enterprise level risk assessment. The number of factors to assess and the manner in which threats and vulnerabilities intermingle render actual dollar amounts, time spent, etc. simply too difficult to determine with any accuracy. That is why the vast majority of risk assessments carried out by organizations are qualitative in nature.

However, whether qualitative or quantitative risk assessments are performed, the key to their overall usefulness is the accuracy you achieve in uncovering valid threats, finding all vulnerabilities, determining the true likelihood of occurrence and accurately calculating the impact to the organization. Garbage in then garbage out no matter which method you use.

ClawBack For Credit Unions

Posted on by
Reply

I got a question recently from one of our Credit Union clients about ClawBack™. They explained that they don’t really do any internal development, so leaking source code was not a concern for them. Based on that, they wondered, would ClawBack still be a useful tool for them?

I pointed out that most larger Credit Unions do some form of development, or at the very least, that their systems admin folks often write (and potentially expose) scripts and other management tools that would be of use to an attacker. However, even if they didn’t do any development at all, leveraging something like the Professional level of ClawBack as a DIY tool ($149.00 per month) is still a good idea.

Further, I explained that source code leaks are only one third of the focus of the ClawBack tool. It also searches for leaked device/application configurations and leaked credentials. Every Credit Union with a network needs to think about leaked device and application configurations. These are the most commonly found items in ClawBack’s history. Whether by accident, or misunderstanding or malicious intent, thousands of leaked configuration files wind up on the Internet in repositories, support forums, answer sites, social media and paste bins. When found, they can provide significant amounts of damaging information to attackers, ranging from logins and passwords to sensitive cryptography and API keys. In some cases, they can be a nearly complete map of the internal network.

Thirdly, ClawBack also focuses on leaked credentials. It can help identify stolen and compromised passwords belonging to members of your organization. Many times, these credentials contain the same or similar passwords as Internet exposed applications, webmail or email access and potentially even weakly secured VPN instances. Stolen and leaked credentials are among the most significant root causes of breaches, business email compromise and a variety of other fraud.

Your CU Security team can add ClawBack to their toolkit for less than $150 per month. It’s simple to use, flexible and an incredibly powerful capability to minimize the damage from data leaks. Check out this less than 8 minute video for more information. If you’d like to discuss ClawBack or our ClawBack Managed and Professional Services, please drop us a line, or give us a call at (614) 351-1237 today. 

Closing the CUSO Security Loop Hole

Posted on by
Reply

The CUSO Security Loop Hole

The NCUA Inspector General (IG) suggested this week that the agency have regulatory oversight of Credit Union Service Organizations (CUSOs) to reduce the overall risk to the system. CUSOs have long been seen as a separate firm from the credit unions, though they may have an ownership stake in them. To date, many of these organizations have been outside the regulatory and oversight controls that are applied to the very credit unions they serve. In terms of information security, that often means they aren’t held to the same level of security and risk management controls as required by NCUA 748 and other guidance.

DigitalMoneyCUSO Security Oversight Challenges

The NCUA IG suggests that NCUA guidance and regulatory oversight be directly applied to CUSOs, instead of through vendor or partner risk management programs of the CUSO customers. This would provide for more direct regulation of the security controls and risk management processes in use at the CUSOs themselves. However, this introduces several challenges for some CUSOs, who may be more focused on agility, market speeds and innovation – areas where regulatory guidance can be especially impactful and can create significant budgetary challenges. This gets even more complicated when regulatory guidance is vague, or can be inflexible – the very opposite of the needs of organizations focused on innovation and market speed adaptation. An excellent example of this is CUSOs working on financial technologies, crypto currencies, blockchain and other exciting new areas. Regulatory guidance lags or lacks in most of those areas and hasn’t caught up to these new, and in some cases, experimental technologies.

One Approach – Best Practices CUSO Security and Third Party Attestation

One approach that might work, is for CUSOs to work with independent third-party assessors who could then measure the CUSO against industry standard best practices that apply to their specific lines of business, research or innovation. These vendors could then help the CUSO build a relevant and respectable CUSO security and risk management program – which they could attest to the NCUA. If this attestation were required on a yearly basis, along with some basic guidance, like ongoing risk management reviews, ongoing vulnerability management, etc – this could go a long way to mitigating the risks that concern the NCUA IG, while still maintaining independence and control by the CUSOs – thus, empowering their mission. Programs like these have been very successful in other industries and don’t have to add the overhead and bureaucracy of full regulatory compliance or programs like PCI-DSS. 

If you’d like to build such a program for your CUSO, please get in touch with us. We’d love to work on creating this process with a handful of CUSOs around the US, and are more than capable of applying our 30 years of experience in information security to each organization’s independent needs. Drop us a line or give us a call at (614) 351-1237 and let’s work together to close the CUSO Security loop hole in a way that reduces risk but doesn’t destroy the power and flexibility of the CUSO ecosystem.

3 Things Attackers Can Leverage From a Device Configuration Leak

Posted on by
Reply

One of the questions I often get around our ClawBack data leak detection SaaS product is “What can a hacker get from a leaked config?”. I put together this quick post about three of the most common and powerful elements that we often find in leaked configurations we discover.

1) Credentials – Let’s face it, credentials are often the easiest way to leverage leaked configs. Sure, it might be for an edge router or some network gear, or maybe it’s for the VPN. Configs often contain sets of credentials, either in plain text or in hashed form. Hashes need to be cracked, sure, but that is often quite possible. Even when the credentials aren’t able to be used remotely, they often help us tune our password guesses and learn more about the policies and password requirements of other systems. You wouldn’t believe the number of times, though, that the credentials from a leaked config simply work across the network or enterprise and often at a significantly powerful level. 

2) Encryption Keys – Leaked router, firewall or VPN device configurations often contain encryption keys. While these still require an attacker to be in a position to gather traffic, they are very useful to well resourced attackers with that capability. If you’re at the level of risk where you need to worry about nation-state or politically motivated attackers, you really don’t want to leak your encryption keys. In addition to simply being a significant issue going forward, leaking encryption keys is a “long tail” vulnerability, because it provides cryptanalysis capabilities to adversaries who might have historic traffic archived, that the leak makes possible for them to leverage. Thus, the life of the key becomes the window of vulnerability. This is especially true when static cryptographic protocols are in use.

3) Network Recon Data – From IP addresses to firewall rules and from SNMP strings to dynamic routing data, device configurations can provide a veritable treasure trove of recon data about your environment. Partner connections, vendors with remote access, interconnects with other environments and the general day to day operations of the computing systems can often be found in leaked configurations. Depending on the type and criticality of the device, the config can often give up a complete view of the guts of the organization.

That’s just the top 3. We’ve seen thousands of leaked configurations in our work on ClawBack and penetration testing. It’s no doubt that leaked configs are useful to the attacker. The big question is, if you had leaked configurations out in the world, would you know about it? Would you know how to hunt them down, claw them back and mitigate the damage? If not, or if the idea makes you nervous, give us a call. We’re happy to help you solve these problems. You can get in touch by calling 614-351-1237 or drop us an email at info@microsolved.com. 

ClawBack Professional and Managed Services Launched

Posted on by
Reply

Clawback small

ClawBack™, our data leak detection engine which we released last fall, is a cloud-based SaaS tool focused on helping organizations detect leaked source code, device/application configurations and credentials. You can learn more about the product and why we made it in this quick 8 minute video by clicking here.

While ClawBack has been a very successful product in its own right, the SaaS platform is primarily “Do It Yourself” in terms of operations. It’s easy to use and manage, but the customer does the work of reviewing the alerts and managing the responses. Over the last several months, some clients have asked for a managed service option, where MSI will manage the ClawBack product, review the alerts and work with the customer to issue take downs or provide mitigation advice. Today, we are proud to announce the immediate availability of the ClawBack Managed Service. Now you can get the power and vigilance of ClawBack without the overhead of managing and monitoring the product directly, reviewing the alerts and issuing appropriate take down requests.

Several clients have also asked us about other professional services associated with ClawBack and with Data Leak Prevent/Protection (DLP) capabilities in general. MSI is also proud to announce the immediate availability of the following associated professional services:

  • Monitoring term identification, optimization and improvement
  • Watermark implementation in source code and device configurations
  • Data leak awareness training, especially focused on source code, configurations and credentials
  • Data leak impact modeling and table top simulations
  • 30/60/90 day data leak assessments
  • Exfiltration testing and Data Loss Prevention (DLP) assessments and optimization
  • Data classification and data leak policy and process development and reviews

Additionally, we are launching multiple year packages that combine these services in 3 and 5 year plans, allowing our clients to create long term solutions to the problems of data leakage, intellectual property risk management and compromises stemming from leaked source code, configs and credentials. To learn more about these services or create a package that fits your firm’s needs, give us a call at 614-351-1237 or drop us a line (info@microsolved.com).

WARNING: Migrate Windows Server 2003 Immediately

Posted on by
Reply

Believe it or not, we still get queries from a few utility companies that have operational processes locked on Windows Server 2003 as a platform. Most of the time, these are legacy applications associated with some form of ICS device or data management system that they have not been able to afford to replace.

Windows 2003 Server end-of-life searches are still among the most popular searches on our StateOfSecurity.com blog, receiving more than 200 queries most months. Keep in mind, this is an operating system that patches haven’t been released for since 2015. According to Spiceworks, an online community for IT professionals, the Windows 2003 Server operating system still enjoys a market share of 17.9%, though we could not validate the time frames of their claim.

But, just in the last year or so, we have seen it alive and well in natural gas, energy and the communications infrastructures, both foreign and domestic. So, we know it is still out there, and still being used in seemingly essential roles.

I’m not going to lecture you about using a system that is unmatched for 5 years. That’s just common sense. Instead, what I am going to do is make three quick suggestions for those of you who can’t get rid of this zombie OS. Here they are:

1. Install a firewall or other filtering device between the legacy system and the rest of your environment. This firewall should reduce the network traffic allowed to the system down to only specifically required ports and source addresses. It should also restrict all unneeded outbound traffic from the device to anything else in the network or the world. The device should be monitored for anomalies and security IOCs.

2. If the hardware is becoming an issue, as well, consider virtualizing the system using a modern virtualization solution. Then apply the firewalling above. Server 2003 seems to be easily virtualized and most modern solutions can handle it trivially.Hardware failure of many of these aging systems is their largest risk in terms of availability.

3. Eliminate the need AS SOON AS POSSIBLE. Even with the firewalling and filtering, these systems have high risk. You might also consider if you can migrate portions of the services from Windows 2003 to a more recent system or platform. This isn’t always possible, but everything you can move from Windows 2003 to a supported OS is likely to let you crank down your filtering even more.

Lastly, if you’re still trapped on Windows 2003, make sure you review this every quarter with the application owners and management. Keep it on their mind and on the front burner. The sooner you can resolve it, the better. 

If you need more help or advice on risk mitigation or minimization, get in touch. We’d love to help! Just email us at info@microsolved.com and we can connect.

EDI – The Often Overlooked Critical Process in Utilities

Posted on by
Reply

EDI (Electronic Data Interchange) is an often forgotten underpinning of many utility companies, even though many of its functions are likely to be critical to the operation. In many states, EDI is a mandated operation for commercial bill pay and meter reading data exchange with third party services. In fact, between the Gas Industry (GISB) and North American Energy (NAESB) Standards Boards, a substantial set of requirements exist for industry use of EDI.

Data

While EDI exists as a specific set of functions for exchanging digital data, it is often managed through third party applications and networks. These operations carry several different threat models, from disruption of service and outages that impact the data availability, to tampering and compromise of the data in transit. As such, it is essential that utilities have performed business function and application specific risk assessment on EDI implementations.

Additionally, many of our clients have performed EDI-focused penetration testing and technical application assessments of their EDI translators and network interconnects. Some clients still utilize a Value Added Network (VAN) or other service provider for EDI transmissions, and MSI can work with your VAN to review their security program and the configuration of your interconnections to ensure maximum security and regulatory compliance.

Lastly, our team has been very successful doing tabletop incident response and disaster recovery/business continuity exercises involving modeling EDI outages, failures and data corruption. Impacts identified in these role playing exercises have ranged from critical outages to loss of revenue.

If you’d like to learn more about our EDI services and capabilities, give us a call at 614-351-1237 or drop us a line at info@microsolved.com. We’d love to talk with you about our nearly 30 years of experience in EDI, information security and critical infrastructure.

 

 

 

Announcing the Launch of the SecureDrive Alliance

Posted on by
Reply

LMS Consulting and MicroSolved are proud to announce the launch of the SecureDrive Alliance. This team effort is specifically focused on the needs, regulatory requirements and threats facing automotive dealerships today.

SecureDrive Alliance

The alliance will be providing the following focused services to dealerships across the US:

  • Risk assessments
  • Vulnerability assessment and penetration testing
  • Application security
  • Phishing simulations
  • Risk management training

To learn more about the SecureDrive Alliance, the leaders of both companies have put together a quick MP3 discussing the reasons behind the launch and the capabilities that the alliance brings to bear. You can listen to the 9 minute MP3 here.

To put the team to work on securing your dealership, give a call to Justin LeBrun, or drop him an email.

What Do I Need To Know About Source Code Leaks?

Posted on by
Reply

Leaked source code happens a lot more frequently than most of our clients care to admit. Often, many clients are surprised when they begin using ClawBack™ to hunt for and take down leaked source code, configuration data and credentials. Most customers tell us they expect not to find anything at all, and many times they are simply astounded when their initial monitoring reports find critical examples of leaked source code out in the wild.

At MSI, however, we’re not surprised when these things happen. After all, that’s why we built ClawBack to begin with. We were tired of working incident after incident and breach after breach that resulted from these leaks. We knew we had to create a better way for our clients to stay on top of leaked source code, configurations and credentials.

Why Source Code Matters

When we talk about leaked source code with clients, most are worried about the loss of intellectual property. That’s a fair risk assessment, and the impacts can be long standing. Take for example, the leak of RSA source code in 2011, that underlined their flagship SecureID product, and was perpetrated via an external hacking team. The SecureID token is used to add a layer of security into the login process for corporate networks and applications. This meant that the very heart of security in an organization that used these tokens was at risk. In the end, RSA had to replace all of the SecureID devices in circulation. The cost to RSA hit $66 million in terms of replacing the physical tokens. However, other intangible costs such as reputation have a longer and less quantifiable reach. (stop-source-code-theft.com)

But, while we know that intellectual property loss can be an issue, we’ve seen many breaches stem from leaked code. In fact, an estimated 75% of security breaches are enabled when developers code secret access keys and passwords into source code. (assembla.com) We’ve seen it time and time again, across verticals from manufacturing to healthcare and from banking and finance to critical infrastructure. Source code leaks are often a powerful tool of the attacker.

How Source Code Leaks

External hackers are certainly a significant threat to source code security, as seen in the RSA leak above. But hackers are responsible for a far smaller percentage of leaks than you would expect. Instead, the majority of source code leaks come from human mistakes. 

According to Wikipedia, source code leaks are usually caused by misconfiguration of software like CVS or FTP which allow people to get source files through exploits, software bugs , or employees that have access to the sources or part of them revealing the code. (en.wikipedia.org) We agree with this stance, since the majority of leaks ClawBack finds for clients end up getting traced back to misconfigurations of IDE plugins or developers not checking carefully which code repository they are committing their code to. 

Yet another common root cause of code leaks found by ClawBack has been developers sharing code they developed at different companies as a part of their resume and portfolio. While this is very common for freelancers, consultants and contractors, several significant leaks have also been traced back to the portfolios of full-time employees.

A good source code security awareness program and ongoing auditing of plugins, configurations and repositories are strong controls to reduce these risks. After all, as several firms have found out the hard way, even approved and well-known code repositories, that began as open source contributions or accepted projects for sharing with the public, can drift into leaking critical confidential data before you know it. That’s why keeping an eye on all repositories, even the ones fully approved to be public, is essential. If you need help with any of these controls, don’t worry, MicroSolved is here to help with any or all of them.

How Can ClawBack Help With Leaked Code?

ClawBack stands ever-vigilant, continually searching for and hunting down code that leaks from your organization. You configure monitoring terms, using MSI’s documented process, experience and guidance, and set ClawBack to work. Since it serves as an independent third party, it doesn’t rely on monitoring your network or workstations like traditional Data Leak Protection (DLP) products. In fact, almost all of our clients have extensive DLP instances, but still find leaked code. Traditional DLP often focuses on common PII/PHI data types, and even more concerning, the majority of the leaks our clients have found with ClawBack actually get traced back to origins outside of the company network and computing environment – a fact that renders traditional DLP powerless.

ClawBack monitors for your terms in the most common areas of the Internet where source code leaks occur. It searches thousands of code repositories, product support sites, question and answer forums and other nooks and crannies of the web where code samples and such are likely to end up. Once identified, ClawBack alerts you to the presence of your critical data and provides advice on “clawing back” that critical information with takedown requests and search engine cleanup.

Overall, ClawBack serves clients as a watchful eye for leaked source code. It can mean the difference between code being available for minutes versus years, and between a leak and a breach. If you’d like to learn more about ClawBack, give us a call today (614-351-1237) or drop us a line (info@microsolved.com). We’d love to tell you how ClawBack can work for you! 

Small Businesses Need to Have an Incident Response Plan in Place

Posted on by

Many small businesses have a problem they may not even be aware of: they don’t have an incident response (IR) plan in place. This is a problem they should fix, especially with the Covid emergency multiplying the already plentiful malware and social engineering attacks that appear each day. Small businesses often have limited funds and personnel for IT security, and incident response may end up near the bottom of their priority lists. However, not having the ability to react quickly and correctly when an incident strikes can end up costing far more that setting up a basic IR plan and program. Plus, putting together such plan need not be difficult at all. Below are some simple steps small businesses can take to set up their own IR plan.

  • Identify likely security incidents that could impact your business. This information can easily be found on the Internet. Write this down.
  • Decide how the business should react to each one of these incident types and write this down. This advice is also readily available online. Write this down.
  • Decide which personnel are going to be responsible for handling incidents (the incident response team). This usually includes IT and management personnel of various levels. Other personnel like legal advisors and security experts should also be identified. Once the team is chosen decide who is going to be in charge of response efforts. This is the person first contacted once an incident is detected. Write this down.
  • Decide how and what you are going to communicate not only among the team, but with employees, customers who have been affected, regulators, law enforcement personnel, news media, third party security service providers, etc. Also decide who is going to do these communications. Make sure phone lists are included in this document. Write this down.
  • Take all the information from above that you have written down and consolidate it into one plan.
  • Train your personnel what their responsibilities are and who they should contact if they detect an incident. This includes both the team and employees.
  • Finally practice the plan and make adjustments and improvements as needed. A good way to practice incident response is by performing table top exercises that are as realistic as possible.

The above is a very simplified version of an incident response program, but it is really all you need to get started. Having such a plan in place is a kind of insurance that could pay real dividends if a data breach or other serious incident occurs.