It’s almost time for another CMHSecLunch! This month, the event is May 13th, 11:30a – 1pm at Easton Mall food court. As always, it is FREE and open to anyone interested in infosec and IT to attend. You can find out more, track the event and RSVP all one page by clicking here.
We hope to see you there!
This time around, we have a question from a reader named John: “I work in a small financial institution and we have problems with physical access to our computers. Many of our workstations sit in semi-public areas and could easily be attacked with USB devices or physical access when a teller or customer service person leaves the customers alone with the machine at a desk or cubicle. What advice do the experts have to help counter these types of attacks?”
Bill Hagestad started the conversation:
Recommended Points for mitigating this digital & physical vulnerability;
1) Remove workstations from semi-public areas; 2) Deploy & install single – purpose Internet workstations at no more than 2 public locations with VERY limited access to financial institution records only after 3 factor authentication has been authorized by credentialed users only; 3) Set time limites on inactive sessions on all banking terminals to logoff after physical proximity to machine exceeds 15 seconds; 4) Enforce 32 random, alpha-numeric character password changes to all critical financial institutional systems weekly; and, 5) Implement and /or continue aggressive financial institution information assurance education program with goal of 100% employee participation; review/update monthly and, 6) Mandate information security and awareness program participation from financial institution leadership throughout all employees and ranks within the organization.
John Davis expanded: I know how difficult this is for financial institutions. Your customer service representatives need computers in their cubicles in order to provide service to your customers, while at the same time those same computers are a main point of physical vulnerabilitiy. Easy steps can be taken, though, to harden these work stations.
First, workstation users should be allotted local administration rights on their systems only when a business need is present. So, CSR workstations should have their USB and DVD ports disabled. Furthermore, their is no need for them to have the ability to upload or download software. In addition, workstations in publicly accessible areas must be turned off each and every time they are unattended. Perhaps you could implement a system similar to the cut off device used on treadmills or at casinos: CSRs would have to clip a device from their clothing to the workstation before it will work. You could accompany this with biometric access for quick and easy access for the users.
Jim Klun added:
From my experience, and assuming the worst case of Windows systems configured as normal workstations with end-users having admin level access, some immediate things I would do:
1. Disable all removable media access at the hardware ( i.e. BIOS) level. At minimum: disable ability to boot from such sources. or: remove all DVD and CDROM drives and physically disable USB ports. (e.g. glue) 2. Ensure all workstations log activity and ensure that the logs are directed to a central log repository and reviewed. Example: http://www.intersectalliance.com/projects/SnareWindows/ 3. Ensure surveillance cameras cover workstation areas. 4. Aggressive screen-lock settings 5. Removal of admin access for all but limited support staff if at all possible. 6. Consider Usage of security cabinets for workstations: Example: http://www.globalindustrial.com/g/office/computer-furniture/cabinets/orbit-side-car-cabinet 7. Network Access Control to limit what devices are allowed on the local network. That unattended RJ45 jack or poorly secured wireless environment is as much a threat as that USB port or CDROM. Bluetooth setting should also be reviewed. 8. Ensure all sensitive information traveling over the local LAN is encrypted. 9. Use a firmware password ( e.g drivelock or a BIOS power-on password) to limit who can boot the machine. 10. Monthly re-iteration of security policies – including need to lock workstations. In my experience such messages are best tied to real-world examples. It makes the risk real – not just an abstract “security guy” worry. For example, this event could be used to ensure employees are aware that an unlocked workstation could lead to the installation of malware: http://news.techworld.com/security/3256513/sovereign-bank-and-penfed-warn-customers-after-keyloggers-are-found-on-laptops/
I note that both JD and Bill talk about enhanced authentication – including the use of proximity devices. Using such devices ( mostly bluetooth ) to secure these workstations sounds like a great idea to me and may be the easiest and most effective solution. Once the financial institution walks away from the workstation – it’s locked and ideally will not boot. http://btprox.sourceforge.net/ – open source Google “computer proximity lock” for a number of commercial alternatives.
Adam Hostetler closed the conversation with:
Everyone has really good suggestions so far. I am a fan of the simple phsyical solutions. I would put the workstations in locked cages. This would prevent any malicious people from inserting USB devices or CDs, or implanting sniffers between the keyboard and USB ports. Additionally, follow the other advice of disabling them through software, just to be sure.
Another solution may be to move to a thin client solution. It is possible to buy thin clients that have no USB ports or optical drives. This would also ensure that no sensitive information was on the workstation, in the event that it was stolen.
April’s touchdown task for the month is a suggestion to update your contact list that you should have included in your incident response policy.
A few minutes now to make sure the right people are in the list and that their contact information is current could pay off largely down the road. It might also be a good time to check to make sure your contact process has been updated to include SMS/texting, Skype and/or other supported technologies that may have not been around when your policy was last updated.
Just a quick update on the Stolen Data Impact Model (SDIM) Project for today.
We are prepping to do the first beta unveiling of the project at the local ISSA chapter. It looks like that might be the June meeting, but we are still finalizing dates. Stay tuned for more on this one so you can get your first glimpse of the work as it is unveiled. We also submitted a talk at the ISSA International meeting for the year, later in the summer on the SDIM. We’ll let you know if we get accepted for presenting the project in Nashville.
The work is progressing. We have created several of the curve models now and are beginning to put them out to the beta group for review. This step continues for the next couple of weeks and we will be incorporating the feedback into the models and then releasing them publicly.
Work on phase 2 – that is the framework of questions designed to aid in the scoring of the impacts to generate the curve models has begun. This week, the proof of concept framework is being developed and then that will flow to the alpha group to build upon. Later, the same beta group will get to review and add commentary to the framework prior to its initial release to the public.
Generally speaking, the work on the project is going along as expected. We will have something to show you and a presentation to discuss the outcomes of the project shortly. Thanks to those who volunteered to work on the project and to review the framework. We appreciate your help, and thanks to those who have been asking about the project – your interest is what has kept us going and working on this problem.
As always, thanks for reading, and until next time – stay safe out there!
MicroSolved, Inc. is proud to announce a unique event for those interested in information security.
The 2013 International Cyber Threat Intelligence Briefing, featuring internationally recognized author William Hagestad, is an executive level briefing on the latest cyber threat intelligence from around the world. This briefing will provide a unique opportunity for C-Level decision makers to understand the cyber threat to their organizations through the loss of intellectual property via the determined use of cyber espionage. Attendees will be presented with two commercial case studies focusing on Global 50 companies. Recommendations, Short & Long Term Moves will accompany this interactive cyber threat intelligence briefing.
This is an opportunity for your management team to participate in a frank, focused discussion about the international cyber threats organizations face today in the global marketplace.
To learn more or sign up to participate, please register by clicking here.
In our first two blogs concerning Distributed Denial of Service (DDoS) attacks and small service industries, we presented measures organizations can take to prepare for and defend against DDoS attacks. In this final installment on the subject, we will discuss methods of response to these incidents.
The first thing to do when you think you are under DDoS attack is to not panic. Calm and considered responses are always more effective than immediately jumping in and possibly cutting off legitimate connection requests. An ill-considered response on your part could cause the very denial of service your attacker intended in the first place. The best thing you can do is to immediately access your incident response plans and begin to implement those pre-planned procedures you worked so hard on. We are constantly amazed at how many organizations fail to follow their own response planning in the heat of a real incident!
The next step in the process is traffic (log) analysis. You need to be able to identify what type of attack is being perpetrated and the kinds of bogus requests that are being made. This is where large log capacities and log aggregation tools come in very handy. Being able to view a large amount of data from a central console truly helps you recognize patterns in the attack. Since application layer attacks that employ IP spoofing are presently being used, pattern and type recognition are often the only means you have to discern good traffic from bad.
Once you are able to get a handle on what the bad traffic looks like, you can start filtering it out. This is best done by appliances as close to the network edge as possible. You can also work with your ISP which may be able to assist with filtering as well as other mechanisms such as rate and connection limiting.
After the attack is under control, don’t forget to work with law enforcement agencies such as the FBI and US-CERT. They are interested in these events and may be able to assist you in finding and dealing with the perpetrators. Reporting incidents is important because it is crucial to know the number and types of DDoS attacks that are really taking place out there in order to effectively respond to them. Reporting ends up being good for everybody!
Finally, it is very important to conduct lessons learned meetings and to adjust your incident response and business continuity planning. Table top exercises and other incident preparation techniques are helpful, but nothing helps you learn the hard lessons like a real incident. Why waste the only valuable thing to come out of the whole mess!
Columbus, Ohio; April 10, 2013 –MicroSolved, Inc. is proud to announce the addition of Bill Hagestad to the team. Bill is one of the most internationally recognized subject matter experts regarding the People’s Republic of China and her use of the computer as a weapon system.
Prior to joining MSI, Bill created the Red Dragon Rising website which is dedicated to the identification and analysis of foreign language cyber threats. He has authored numerous papers related to the People’s Republic of China and the cyber demagoguery that revolves around the Middle Kingdom. Bill literally wrote the book on Chinese cyber warfare ~ “21st Century Chinese Cyberwarfare”, which is available on Amazon.com. The international intelligence, law enforcement and military experience from the cyber realm that Bill brings to MicroSolved is a very welcome addition to MSI’s industry leading
capabilities offered to clients for more than twenty years.
“We are very excited about Bill joining the team and about his emerging role in developing new relationships and offerings for our clients.”, said Brent Huston, CEO of MicroSolved. “With our growth in the critical infrastructure markets in the last several years and our continued focus on bringing rational information security products and services to ICS asset owners, utilities, government agencies and banks/credit unions, Bill brings us significant additional threat intelligence and educational capabilities. After turning 20 years old last November, we wanted to position MicroSolved to bring new, even more valuable insights to our customers and the community – and that begins with deep knowledge about the global threat landscape.”, he added.
About MicroSolved, Inc.
MicroSolved, Inc. was founded in 1992, making it one of the most experienced information security services companies in the world. Providing risk assessment, ethical hacking, penetration testing and security intelligence to organizations of all sizes has been their passion for more than two decades. MSI are the inventors of HoneyPoint Security Server, a patented honeypot intrusion detection platform designed for nuance and anomaly detection. Today, they secure businesses on a global scale and still provide expertise close to home. From governments to the Fortune 500 and from small business to YOUR business, they are the security experts you can trust.
Press Contacts
Brent Huston
CEO & Security Evangelist
(614) 351-1237 x201
Info@microsolved.com
Bill Hagestad
Senior Cyber Security Strategist
(614) 351-1237 x 250
Info@microsolved.com
Recently, I caught up over email with Bill Sempf. He had some interesting thoughts on software security, so we decided to do a 3 Tough Questions with him. Check this out! :
A short biography of Bill Sempf: In 1992, Bill Sempf was working as a systems administrator for The Ohio State University, and formalized his career-long association with inter-networking. While working for one of the first ISPs in Columbus in 1995, he built the second major web-based shopping center, Americash Mall, using Cold Fusion and Oracle. Bill’s focus started to turn to security around the turn of the century. Internet driven viruses were becoming the norm by this time, and applications were susceptible to attack like never before. In 2003, Bill wrote the security and deployment chapters of the often-referenced Professional ASP.NET Web Services for Wrox, and began his career in pen testing and threat modeling with a web services analysis for the State of Ohio. Currently, Bill is working as a security-minded software architect specializing in the Microsoft space. He has recently designed a global architecture for a telecommunications web portal, modeled threats for a global travel provider, and provided identity policy and governance for the State of Ohio. Additionally, he is actively publishing, with the latest being Windows 8 Application Development with HTML5 for Dummies.
Question #1: Infosec folks have been talking about securing the SDLC for almost a decade, if that is truly the solution, why haven’t we gotten it done yet?
For the same reason that there are still bugs in software – the time and money necessary to fix things. Software development is hard, and it takes a long time and lots of money to write secure software. Building security in to the lifecycle, rather than just waiting and adding it to the test phase, is just prohibitively expensive.
That said, some companies have successfully done it. Take Microsoft for instance. For a significant portion of their history, Microsoft was the butt of nearly every joke in the security industry. Then they created and implemented the MSDL and now Microsoft products don’t even show up on the top 10 lists anymore. It is possible and it should be done. It’s just very expensive, and companies would rather take on the risk than spend the money up front.
Question #2: How can infosec professionals learn to better communicate with developers? How can we explain how critical things like SQL injections, XSS and CSRF have become in a way that makes developers want to engage?
There are two fronts to this war: the social and the technical. I think both have to be implemented in good measure to extract any success.
On the social side, infosec pros need to get out of the lab, and start talking at developer conferences. I have been doing this as a good measure since 2010, and have encouraged other community members to do the same. It is starting to work. This year at CodeMash, Rob Gillen and myself gave a day long training on everything from malware analysis to Wi-Fi to data protection. The talk was so popular that we needed to be moved into a bigger room. Security is starting to creep into the developers scope of vision.
Technically, though, security flaws need to be treated just like any other defect. The application security test team needs to be part of QA, treated just like anyone else in QA, given access to the defect tracking system, and post defects against the system as part of the QA process. Until something like the Microsoft SDL is implemented in an organization, integrating security testing with QA is the next best thing.
Question #3: What do you think happens in the future as technology dependencies and complexities ramp up? How will every day life be impacted by information security and poor development/implementations?
More and more applications and devices are using a loosely connected model to support fast UIs and easy functional development. This means more and more business functionality exposed in the form of SOAP and REST services. These endpoints are often formerly internal services that were used to provide the web server with functionality, but are gradually being exposed in order to support mobile applications. Rarely are they fully tested. In the short term future, this is going to be the most significant challenge to application security. In the long term, I have no idea. Things change so fast, it is nearly impossible to keep up.
Thanks to Bill for sharing his insights. You can discuss them with him on Twitter, where he is @sempf. As always, thanks for reading!
In our first blog about Distributed Denial of Service (DDoS) attacks and small service industries, we discussed measures that organizations should take to prepare themselves for DDoS attacks. In this second installment, we will go over some methods that are useful in defending networks from these attacks. (The third and final installment in this series will deal with responding to DDoS attacks).
One good way to defend your network from DDoS attacks is to hire a service organization that specializes in the problem. They typically employ algorithm-based firewalls, large networks, monitoring, and other techniques to thwart these attacks, and can be very effective. However, these services are also pretty expensive and impractical for smaller organizations unless the threat level is very high indeed. The good news is that you can do a lot to defend yourselves from DDoS attacks.
The first step is knowing exactly what it is that you are defending. Computer networks tend to grow organically and it is a sad fact that most organizations have a very imperfect picture of how their networks are set up and how they behave. To defend against DDoS, it is important to know what typical network traffic looks like throughout the business year. This helps you set proper thresholds for automated detection devices and ensures quick detection of the onset of events such as DDoS attacks.
Another step you can take to help defend against DDoS attacks is to consider a cloud-based approach for your web services. With the traffic volumes DDoS attacks can currently generate, internal web servers at smaller organizations are sure to be overwhelmed. But by employing a content distribution network in a cloud setting you vastly increase your capacity, reduce the chance of any one server becoming unserviceable and are able to deal with the event more efficiently.
It is also important to work with your Internet Service Provider (ISP) during DDoS attacks. Your ISP could help in many ways including source blocking, scrubbing, load distribution and rate limiting. In addition, it should be remembered that many DDoS attacks are launched as diversions to cover up other attacks against organizations. Ensuring that your network is properly enclaved and monitored can go a long way in protecting your information and control assets during these attacks.
This series is written by John Davis, MicroSolved, Inc.
This post introduces a 3 part series we are doing covering distributed denial of service attacks (DDoS) and helping organizations prepare for them. The series will cover 3 parts, Prepare, Defend and Respond.
Part 1 of 3 – Prepare.
Distributed Denial of Service (DDoS) attacks use networks of compromised computers (botnets) or web servers (brobots) to flood organization websites with so much traffic that it causes them to fail. This is especially worrying for financial institutions and utilities which rely so very heavily on the availability of their services and controls. DDoS attacks are also mounted by attackers to hide fraud or other hacking activities being perpetrated on networks. Although these types of attacks are not new, they are presently increasing in frequency and especially in sophistication. Application layer DDoS attacks do a good job of mimicking normal network traffic and recent DDoS attacks have been measured at a huge 65 Gb (nearly 10 times the previous high point). The purpose of this blog is to discuss some methods small organizations can employ to properly prepare for DDoS attacks. (Later articles in this series will discuss means for defending against and responding to these attacks).
The first thing any organization should do in this effort is proper pre-planning. Ensure that DDoS is included in your risk assessment and controls planning efforts. Include reacting to these attacks in your incident response and business continuity plans. And as with all such plans, conduct practice exercises and adjust your plans according to their results. In all our years in business, MSI has never participated in a table top incident responce or disaster recovery exercise that didn’t expose planning flaws and produce valuable lessons learned.
Next, your organization should consider DDoS when choosing an ISP. It helps immensely to have an Internet provider that has enough resources and expertise to properly assist if your organization is targeted for one of these attacks. Ensure that you develop a close relationship with your ISP too – communicate your needs and expectations clearly, and find out from them exactly what their capabilities and services really are.
Finally on the preparation side of the problem, make sure that you keep well informed about DDoS and the actual threat level it poses to your organization. Keep active in user groups and professional organizations. Use the net to gather intelligence. The Financial Service Information Sharing and Analysis Center (FS-ISAC) has plenty of useful and up to date information on DDoS. You can even turn the World Wide Web against the enemy and use it to gather intelligence on them!
–This article series is written by John Davis of MSI.
PS – This is NOT a problem you can “purchase your way out” of. Organizations can’t and should not buy huge amounts of bandwidth as a preparation for DDoS. The cost impacts of such purchases are not effective, nor is bandwidth size an effective control in most cases. Note that some technology solutions for packet scrubbing and the like do exist. Your milage may vary with these solutions. MSI has not reviewed or tested any of the DDoS technology products as a part of this series.