WARNING: Migrate Windows Server 2003 Immediately

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

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

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?

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

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.

Wealth Management Firms: Keep Your Infosec Program Lean but Effective

Wealth Management Firms are under a lot of pressure as regards information security and privacy issues. These firms are regulated by the Securities and Exchange Commission (SEC) and the nongovernmental Financial Industry Regulatory Authority (FINRA) here in America.

In 2016 the SEC itself announced a security breach of their main investor database resulting in over one hundred million dollars in illicit trading profits and other gains. This event was particularly damning and embarrassing to the SEC as the Government Accountability Office had spent the previous eight years warning them about lax security practices.

This caused the SEC to make cybersecurity a priority of its National Exam Program. This program is actually conducted by the SEC’s Office of Compliance Inspections and Examinations (OCIE). Wealth Management Firms are under scrutiny from these examinations as well as those conducted annually by FINRA. The SEC can use its civil authority to bring cyber-related enforcement actions against bad actors, and FINRA has the power to impose substantial fines and penalties (including permanent revocation of registration) for those who fail to comply with their rules.

Unfortunately, all financial institutions suffer under the same vague information security requirements found in the statute laws that they are regulated under. An example of such language from the National Credit Union Administration’s 12 CFR part 748 follows: “1. Identify reasonably foreseeable internal and external threats that could result in unauthorized disclosure, misuse, alteration, or destruction of member information or member information systems…” As you can see, this kind of guidance gives you a goal, but it doesn’t include any specific guidance to tell credit unions how to accomplish it. It’s like that across the body of financial institution regulation.

This basically left it to the regulators themselves to determine what measures financial institutions should take to maintain proper information security. These bodies in response turned to NIST for the basis of their information security guidance. Entities such as the FFIEC, FDIC and OCC all use this guidance as the basis for their own infosec requirements.

Dissatisfaction with this guidance has seen changes and improvements in information security and privacy paradigms in the last decade or so. New thinking in information security recommendations such as the CIS Critical Security Controls and MSI’s own 80/20 Rule of Information Security have started to take hold. The goal of all these newer information security recommendations is to ensure that the most effective infosec controls are prioritized, allowing the user to get the most bang for their information security buck.

My recommendation is that Wealth Management Firms should leverage these programs to meet SEC and FINRA infosec requirements. It would also be advisable to couch these security measures according to the NIST Cybersecurity Framework. This year the focus for OCIE examiners is liable to be:

  • Cyber Governance
  • Cyber Resilience
  • Privacy and Data Security, and
  • Outsourcing Risks

The OCIE also released a handy document called Cybersecurity and Resiliency Observations (https://www.sec.gov/files/OCIE-Cybersecurity-and-Resiliency-Observations-2020-508.pdf). The purpose of this document is to relate security practices that they have observed being used by the industry. It includes sections on Governance and Risk Management, Access Rights and Controls, Data Loss Prevention, Mobile Security, Incident Response and Resiliency, Vendor Management and Training and Awareness. I suggest that Wealth Management Firms should employ these observations when structuring their own information security programs according to the guidance mentioned above. This should provide them with a compliant, effective and low-cost information security program.

Three Things I’ve Learned About Credit Union Risk Management

I have been working with Credit Unions for more than 20 years and have done a wide variety of information security and risk management work over that time. I’ve worked with technical teams, management and boards over the span of more than two decades. Here are three things I’ve learned about how CUs manage risk during that time. 

1) Most credit unions that I’ve worked with care just as much, if not more, about information security than most of the regional size banks they often compete with.

I’ve heard more than one CU leader tell me that they have to be better than the banks, because when a bank gets hacked – that bank makes the news and feels the impact. However, he said, when a credit union gets hacked – all credit unions suffer from the bad press. I am not sure the data supports his claim, but it’s an example of how CUs often focus on working together to solve big problems, and put a lot more attention to detail into it.

2) Many of the credit unions I have worked with look at information security and threat awareness as something that they can offer to their members (“customers, in bank speak”).

More than a few of the CUs have engaged so deeply with their customers on phishing and identify theft, that they include them in discussions about what products and services the CU buys. They do trials, include members in beta-tests and I’ve even seen them do onsite training for how to use new multi-factor authentication tools – even ones that weren’t in use at the CU – just to help make the members more secure and reduce the threat of password re-use across personal sites.

3) The board is often more involved in the risk management process at my CU clients than my banking clients.

The NCUA has taken a lot of steps to increase board member awareness about information security, and it often shows at credit unions. Several times a year, I am asked to present threat updates or review the information security program of a CU, specifically with a presentation to the board in mind. I am often engaged as a third party, to spend a couple of days looking at a security program and reporting to the board on it’s maturity and areas of potential improvement.

During these board sessions, it is not uncommon for the board questions to last more than an hour, after the presentation has completed. The point is, most CU boards that I have worked with are deeply engaged in thinking about risk management at the credit union.

For those of you interested in more about risk management at credit unions, here are some of the best sources, which I refer to often in my presentations:

  • Credit unions also face such internal risks as internal fraud, legal and regulatory noncompliance, data breaches, and injuries to staff and visitors. (boardeffect.com)
  • The bottom line: Figuring out the risk appetite will help guide credit unions to create realistic and measurable risk guidelines. (visibleequity.com)

  • We have helped Credit Unions develop risk appetite statements and risk frameworks and can work with your Credit Union to develop the documentation you require. (creditunionupdate.com)

If you’d like to learn more about MSI and our work with credit unions, just drop us a line (info@microsolved.com) or give us a call (614-351-1237) and we’d be happy to talk about how we might be able to help your credit union excel in IT risk management.

Auto Dealerships: is Your Private Information Safe?

When you think about it, automobile dealerships can have a lot of very detailed and private information about you. For example, when you buy a car, the dealer may collect your identity and location information (name, address, telephone number, email address and even information about family members and pets). If you finance the vehicle through them, they also may collect a great deal of financial information about you (Social Security Number, credit history, bank(s) you use, account numbers and credit rating). And, of course, they have detailed information about at least one of your vehicles such as make, model, accessories, vehicle identification numbers, etc. All of this information is very desirable to cyber-criminals and hackers.

Not only do auto dealerships have a lot of your private information, the nature of the business gives online and on-site attackers numerous opportunities to access and compromise this information. Employees and customers move about a great deal in automobile dealerships often leaving their work areas unattended. There are numerous workstations around a dealership from the parts department to the service department to the finance department to the sales departments. If users share their passwords with fellow employees for convenience sake or leave their computers active when they are away from them, compromise of private information is made easy. In addition, auto dealership networks are usually connected to numerous service providers, partners and information systems. If these systems are compromised, then compromise of the dealership system could soon ensue. There are also liable to be paper documents containing private information that could be left exposed on desks or in unlocked drawers.

Luckily, auto dealerships that extend credit to someone, arrange for someone to finance or lease a car for personal, family or household use, or that provide financial advice or counseling to individuals are identified as financial institutions and are regulated by the Federal Trade Commission (FTC) under the Gramm-Leach-Bliley Act of 1999 (GLBA). These businesses therefore are required to comply with the FTC Privacy Rule and the FTC Safeguards Rule. Auto dealerships may also be subject to state or local ordinance, or some private regulatory body such as the PCI DSS. This is a good thing for the consumer.

Under the FTC Privacy Rule, dealerships are required to protect private customer financial information, and are required to provide customers with a number of written notices detailing their rights under the Privacy Rule. Under the FTC Safeguards Rule, dealerships must protect physical, paper and electronic customer information. They are also required to have an information security program designed to protect the confidentiality, integrity and availability of private customer information. Since dealerships are considered to be financial institutions, these security requirements are much the same as those your bank must adhere to. There are fines in place for failure to comply with these regulations, and lawsuits may also be filed against dealerships that fail to adequately protect your private information.

Although these regulations don’t guarantee your private information won’t be compromised, they do put a big roadblock in the path of information thieves. Plus, auto dealers know that 84% of those surveyed said they wouldn’t do business with a dealership that has had a customer data breach incident. That surely helps inspire dealers to take information security seriously.

The New MicroSolved 80/20 Rule of Information Security

In 2009, there was a big effort on the Federal level to establish a consensus among a varied group of information security experts from all sectors as to which information security controls were most effective in the modern computing and networking environment. This was driven by the perception that the Federal Information Security Management Act (FISMA) was ponderous and unable to effectively protect the confidentiality, integrity and availability of private information.

This effort initially led to the publication of the 20 Most Important Controls for Continuous Cyber Security Enforcement: Consensus Audit Guidelines. It also stimulated thinking among organizations and information security professionals about possible variations and adaptations of this guidance. One such effort was the MicroSolved 80/20 Rule of Information Security (2009). While very similar to the Consensus Audit Guidelines, the focus of the 80/20 Rule was to establish a group of security control projects that provided the most “bang for the buck” for the small and medium-sized organizations that don’t typically have the resources of the Federal Government or other large organizations.

Continue reading

Phishers Continue to Capitalize on Covid 19 Emergency

They say that every cloud has a silver lining. That has certainly been true for cyber-criminals during the Covid 19 emergency! While the country as a whole is experiencing 20% unemployment and general hardship, these folks continue to reap the rewards chaos inevitably brings to the larcenous. Here are some of the shenanigans that have darkened the news this week:

One article this week talks about “Hack for Hire” groups in India that are spoofing World Health Organization (WHO) emails to steal access credentials from businesses around the world (including the U. S.). These hacking emails come from hosted websites that are crafted to look like the official WHO website, and claim to provide direct notification from the WHO on Covid 19-related announcements. They are targeting financial services, consulting and healthcare organizations.

Continue reading