Tag Archives: ask the experts

Ask The Experts: Favorite HoneyPoint Component

Posted on by
Reply

This time around, we got a question from a client where HoneyPoint was being demoed for the experts.

Q: “What is your favorite component of HoneyPoint and why? How have you used it to catch the bad guys?”

Jim Klun started off with:

My favorite component is the simplest: HoneyPoint Agent. 

It’s ease of deployment and the simple fact that all alerts from an agent are of note – someone really did touch an internal service on a box where no such service legitimately exists – makes it attractive. 
No one will argue with you about meaning. 

I have recently seen it detect a new MSSQL worm (TCP 1433) within a large enterprise – information obtained from my own laptop. The Agent I had deployed on the laptop had a 1433 listener. It captured the payload from an attacking desktop box located in an office in another US state. 

The HoneyPoint Agent info was relayed to a corporate team that managed a global IPS. They confirmed the event and immediately updated their IPS that was – ideally – protecting several hundred thousand internal machines from attack. 

Honeypoint Agent: It’s simple, it works.

Adam Hostetler added his view:

I’m a simple, no frills guy, so I just like the regular old TCP listener component built into Agent. We have stood these up on many engagements and onsite visits and picked up unexpected traffic. Sometimes malware, sometimes a misconfiguration, or sometimes something innocuous (inventory management). I also find it useful for research by exposing it to the Internet.

John Davis closed with a different view:

My favorite HoneyPoint is Wasp. Watching how skilled attackers actually compromise whole networks by initially compromising one user machine gives me the shivers! Especially since most networks we see aren’t properly enclaved and monitored. If I were a CISO, knowing what is on my network at all times would be of primary importance; including what is going on on the client side! Wasp gets you that visibility and without all the traditional overhead and complexity of other end-point monitoring and white listing tools.

Have a question about HoneyPoint? Want to talk about your favorite component or use case scenario? Hit us on Twitter (@lbhuston or @microsolved). We can’t wait to hear from you. Feel free to send us your question for the experts. Readers whose questions we pick for the blog get a little surprise for their contribution. As always, thanks for reading and stay safe out there! 

Ask The Experts: New Device Check Lists

Posted on by
2

This time around on Ask The Experts, we have a question from a reader and it got some great responses from the team:

 

Q: “I need a quick 10 item or less checklist that I can apply to new devices when my company wants to put them on our network. What kinds of things should I do before they get deployed and are in use around the company?”

 

Bill Hagestad started us off with:

The Top 10 checklist items a CISO/or equivalent authority should effectively manage before installing, configuring and managing new devices on a network includes the following;

 

1)Organize your staff and prepare them for the overall task of documenting and diagramming your network infrastructure – give them your commander’s network management intent;

2)Create a physical and logical network map – encourage feedback from your team regarding placement of new hardware and software;

3)Use industry standards for your network including physical and logical security, take a good look at NIST Special Publication SP 800-XX Series;

4)Make certain that you and your team are aware of the requisite compliance standards for your business and industry, it will help to ensure you are within legal guidelines before installing new devices or perhaps you may discover the hardware or software you are considering isn’t necessary after all;

5)Ensure that after you have created the necessary network maps for your infrastructure in Step 2) above, conduct a through inventory of all infrastructure which is both critical and important to your business, then document this baseline;

6)Create a hardware/software configuration change procedure; or if you already have his inlace, have your team review it for accuracy; make certain everyone on the team knows to document all changes/moves/additions on the network;

7)Focus not only on the correlation of newly implemented devices on the internal networks but also look at the dependencies and effects on external infrastructure such as voice/data networks – nothing worse than making an internal change to your network and having your Internet go down unnecessarily;

8)Ensure that new network devices being considered integrate gracefully into your existing logging and alerting mechanisms; no need to install something new only to have to recreate the proverbial wheel in order to monitor it;

9)Consider the second & third order effects of newly installed devices on the infrastructure and their potential impact on remote workers and mobile devices used on the network;

10)Install HoneyPoint Security Server (HPSS) to agentlessly & seamlessly monitor external and potential internal threats to your newly configured network….

 

Of course a very authoritative guide is published by the national Security Agency called appropriately “Manageable Network Plan” and available for download @:

 

http://www.nsa.gov/ia/_files/vtechrep/ManageableNetworkPlan.pdf


Jim Klun added:

1. Make sure the device is necessary and not just a whim on the part of management.   Explain that each new device increases risk. 

2. If the device’s function can be performed by an existing internal service, use that service instead. 

3. Inventory new devices by name, IP addresses, function and – most importantly – owners.  There should be a device owner and a business owner who can verify continued need for the device.  Email those owners regularly,   querying them about continued need. Make sure that these folks have an acknowledged role to support the application running on the devices and are accountable for its security. 

4. Research the device and the application(s) its support.  Have no black boxes in your datacenter.  Include an abstract of this in the inventory. 

5. Make sure a maintenance program is in place – hold the app and device owner accountable. 

6. Do a security audit of the device wehn fully configured. Hit it with vulnerability scanners and make sure that this happens at least quarterly. 

7. Make sure monitoring is in place and make very sure all support staff are aware of the device and any alerts it may generate. Do not blind-side the operations staff. 

8. If the device can log its activities ( system and application ) to a central log repository, ensure that happens as part of deployment. 

9. Make sure the device is properly placed in your network architecture. Internet-exposed systems should be isolated in an Internet DMZ.  Systems holding sensitive data should similarly be isolated. 

10. Restrict access to the device as narrowly as possible. 

 

Finally.. if you can, for every device in your environment, log its network traffic and create a summary of what is “normal” for that device.  

Your first indication of a compromise is often a change in the way a system “talks”. 

 

Adam Hostetler chimed in with: 

Will vary a lot depending on device, but here are some suggestions

 

1. Ensure any default values are changed. Passwords, SNMP strings, wireless settings etc.

2. Disable any unnecessary services

3. Ensure it’s running the latest firmware/OS/software

4. Add the device to your inventory/map, catalog MAC address, owner/admin, etc.

5. Perform a small risk assessment on the device. What kind of risk does it introduce to your environment? Is it worth it?

6. Test and update the device in a separate dev segment, if you have one.

7. Make sure the device fits in with corporate usage policies

8. Perform a vulnerability assessment against the device. 

9. Search the internet for any known issues, vulnerabilities or exploits that might effect the device.

  1. Configure the device to send logs to your logging server or SEIM, if you have one.

 

And John Davis got the last word by adding: 

From a risk management perspective, the most important thing a CISO needs to ensure is in place before new devices are implemented on the network is a formal, documented Systems Development Life Cycle or Change Management program. Having such a program in place means that all changes to the system are planned and documented, that security requirements and risk have been assessed before devices have purchased and installed, that system configuration and maintenance issues have been addressed, that the new devices are included in business continuity planning, that proper testing of devices (before and after implementation on the network) is undertaken and more. If a good SDLC/Change Management program is not in place, CISOs should ensure that development and implementation of the program is given a high priority among the tasks they wish to accomplish.

 

Whew, that was a great question and there is some amazing advice here from the experts! Thanks for reading, and until next time, stay safe out there! 

 

Got a question for the experts? Give us a shout on Twitter (@microsolved or @lbhuston) and we’ll base a column on your questions!

Ask The Experts: Too Much Data

Posted on by
2

Q: “I have massive amounts of log files I have to dig through every day. I have tried a full blown SEIM, but can’t get it to work right or my management to support it with budget. Right now I have Windows logs, firewall logs and AV logs going to a syslog server. That gives me a huge set of text files every day. How can I make sense of all that text? What tools and processes do you suggest? What should I be looking for? HELP!!!!”

 

Adam Hostetler answered with:

 

I would say give OSSEC a try. It’s a free log analyzer/SEIM. It doesn’t

have a GUI with100 different dashboards and graphs, it’s all cli and

e-mail based (though there is a simple web interface for it also). It is

easy to write rules for, and it has default rules for many things,

except for your AV. You can write simple rules for that, especially if

you are just looking for items AV caught. It does take some tuning, as

with all analysis tools, but isn’t difficult after learning how OSSEC

works. If you want to step it up a bit, you can feed OSSEC alerts into

Splunk where you can trend alerts, or create other rules and reports in it.

 

Bill Hagestad added:

 

First things first – don’t be or feel overwhelmed – log files are what they are much disparate data from a variety of resources that need reviewing sooner rather than later.

 

Rather than looking at another new set to tools or the latest software gizmo the trade rags might suggest based on the flair of the month, try a much different and more effective approach to the potential threat surface to your network and enterprise information network.

 

First take a look at what resources need to be protected in order of importance to your business. Once you have prioritized these assets then begin to  determine what is the minimum level of acceptable risk you can assign to each resource you have just prioritized.

 

Next, make two columns on a either a piece of paper or a white board. In one column list your resources in order of protection requirements, i.e.; servers with customer data, servers with intellectual property, so and so forth. In a column to the right of the first assets list plug in your varying assigned levels of risk. Soon you will see what areas/assets within your organization/enterprise you should pay the most attention to in terms of threat mitigation.

 

After you have taken the steps to determine your own self- assessment of risk contact MicroSolved for both a vulnerability assessment and penetration test to provide additional objective perspective on threats to your IT infrastructure and commercial enterprise. 

 

Finally, Jim Klun weighed in with: 

 

You are way ahead of the game by just having a central log repository.  You can go to one server and look back in time to the point where you expect a security incident.

 

And what you have – Windows logs, firewall logs, and AV – is fantastic.  Make sure all your apps are logging as well ( logon success, logon failure).

Too often I have seen apps attacked and all I had in syslog was OS events that showed nothing.

 

Adam’s suggestion, OSSEC, is the way to go to keep cost down… but don’t just install and hope for the best.

You will have to tweak the OSSEC rules and come up with what works.

 

Here’s the rub: there is no substitute for knowing your logs – in their raw format, not pre-digested by a commercial SIEM or OSSEC.

 

That can seem overwhelming. And to that, some Unix commands and regular expressions are your friend.

 

So:

 

zcat auth.log | grep ssh | egrep -i ‘failed|accepted’

 

produces:

 

Jul  4 16:32:16 dmz-server01 sshd[8786]: Failed password for user02 from 192.168.105.51 port 38143 ssh2

Jul  4 16:33:53 dmz-server01 sshd[8786]: Accepted password for user01 from 192.168.105.38 port 38143 ssh2

Jul  4 16:36:05 dmz-server01 sshd[9010]: Accepted password for user01 from 192.168.105.38 port 38315 ssh2

Jul  5 01:04:00 dmz-server01 sshd[9308]: Accepted password for user01 from 192.168.105.38 port 60351 ssh2

Jul  5 08:21:58 dmz-server01 sshd[9802]: Accepted password for user01 from 192.168.105.38 port 51436 ssh2

Jul  6 10:21:52 dmz-server01 sshd[21912]: Accepted password for user01 from 192.168.105.38 port 36486 ssh2

Jul  6 13:43:10 dmz-server01 sshd[31701]: Accepted password for user01 from 192.168.105.30 port 34703 ssh2

Jun 26 11:21:02 dmz-server01 sshd[31950]: Accepted password for user01 from 192.168.105.70 port 37209 ssh2

 

 

Instead of miles of gibberish the log gets reduced to passed/fail authentication attempts.

 

You can spend an hour with each log source ( firewall, AV, etc) and quickly pare them down to whats interesting.

 

Then make SURE your OSSEC  rules cover what you want to see.

If that does not work – cron a script to parse the logs of interest using your regular expression expertise and have an email sent to you when something goes awry.

 

Revisist the logs manually periodically – they will change. New stuff will happen.  Only a human can catch that.

 

Take a look at:

http://www.securitywarriorconsulting.com/logtools/

 

The site lists a number of tools that may be useful

 

John Davis added:

 

You voice one of the biggest problems we see in information security programs: monitoring! People tell us that they don’t have the proper tools and, especially, they don’t have the manpower to perform effective logging and monitoring. And what they are saying is true, but unfortunately doesn’t let them out from having to do it. If you have peoples financial data, health data (HIPAA) or credit card information (PCI) you are bound by regulation or mandate to properly monitor your environment – and that means management processes, equipment, vulnerabilities and software as well as logs and tool outputs. The basic problem here is that most organizations don’t have any dedicated information security personnel at all, or the team they have isn’t adequate for the work load. Money is tight and employees are expensive so it is very difficult for senior management to justify the expenditure – paying a third party to monitor firewall logs is cheaper. But for real security there is no substitute for actual humans in the security loop – they simply cannot be replaced by technology. Unfortunately, I feel the only answer to your problem is for government and industry to realize this truth and mandate dedicated security personnel in organizations that process protected data.

 

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

Ask The Experts: Daily Tasks

Posted on by
3

This time around, we get a great question from a reader:

Q: “I’m a one man infosec team at a small financial company, and as such, I stay overtasked. Can you give me a few examples of some key tasks I should make sure I am doing daily/weekly/monthly to make sure I am hitting them all and to help me better structure my schedule?”

Bill Hagestad answered with:

Daily Tasks: 

– Keep self and staff educated about latest cyber threats to your business – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Review what Federal Law Enforcement considers top cyber threats are base on current cases:
– Compromise of account holder credentials leading to legitimate account compromise;
-Via  phasing attack vectors; unauthorized ACH transfers; 
– Compromise of Third Party Payment Processors;
 
Source: FBI Threat To Financial Sector
 
-Insider attacks – perhaps the largest threat to any commercial enterprise – especially given the recent NSA dilemma via a US contractor
 
– Have staff follow all account verification standing operating procedures – covering all types of customer interaction, including but not limited to; phone, Internet, and in-person account interactions;
– Information Security/Assurance infrastructure configuration changes should be reviewed daily and approved/counter-approved internally to eliminate potential administrative abuses;
– Hold weekly Information Security/Assurance infrastructure team meetings – invite MicroSolved to participate as a credible resource for staff to ask questions of and make sound recommendations.
 
Weekly Tasks:
 
– Stay ahead of international financial sector threat intelligence – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Ensure account access lists are secure and validated both for external customers (most importantly) and also internal employee need to access/right to access customer account information;
  
Monthly Tasks:
 
– Participate in professional cyber/information assurance mailing lists – if not sure who or what these are contact MSI Cyber Threat Intelligence;
– Be certain to review the US Government Hearing Notes: Cybersecurity: Threats to the Financial Sector downloadable @ http://www.gpo.gov/fdsys/pkg/CHRG-112hhrg72601/pdf/CHRG-112hhrg72601.pdf
– Review or create a cyber threat identification strategy involving key staff and MicroSolved – install HoneyPoint Security Server to capture knowledge about who truly is probing your network, eliminate the proverbial network noise and focus on specific threat actors – e.g.; Russian Cyber Crimianls, Chinese entities using government cyber espionage tools for crime purposes
 
Adam Hostetler added:
It’s hard to answer exactly what you should be doing on a timely basis
without reviewing your current requirements, tools, processes, and
infrastructure. However, If you go to www.microsolved.com and look at
our 80/20 white paper, you can use that as a guideline to give you some
ideas to help build out your security program.

Examples of some things you could/should be doing.

Daily:
Log reviews. Not necessary for all logs, but if you have
IDS/IPS/Honeypots etc, they should be reviewed and investigated if needed
Spend a bit of time following up on the latest security news/threats.
That includes things like new vulnerabilities or exploits, and then
following up if it would affect you.

Weekly:
Check and verify backups and processes

Monthly:
Update software/OS patches.

 
Finally, Jim Klun weighed in with: 
1. Make sure your subscribed to security news-feeds/alerting services that apply to your environment. Review those daily.

2. Make sure you are reviewing your logs daily.  You should know every day about successful and unsuccessful logins. You should also be paying attention to your firewall logs for inbound activity and outbound activity.

3 If you have a local help desk, talk to them at least monthly. They are often in a position to see things that are in fact security problems.

4. Automate your patching program if that is not true already, then review patch reports monthly.

5. If you have Internet exposures, check them monthly. Make absolutely sure at the end of each month you are absolutely sure of what services your organization offers to the Internet – and why.

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

Ask The Security Experts: Holiday Coverage

Posted on by
3

This time around on Ask The Security Experts, we have a question about holiday coverage for the security team:

Q: “With the upcoming summer holidays and heavy vacation schedules, what are some things I need to pay attention to in order to make sure attackers don’t catch us off guard while we are short on staff?”

Jim Klun weighed in with:

1. Make sure all staff have been reminded of the reality of phishing attacks and what they need to watch out for.
   Use real-world examples like this one: http://labs.ft.com/2013/05/a-sobering-day/ ( courtesy of Adam Hostetler )
   Its important that staff understand the potential severity of a successful phishing attack.
   Such attacks are more likely over holiday periods when attackers can rely on short-staffing.

2. Make sure all systems( both network/OS/application ) are logging and that you are reviewing those logs for anomalies
   Make it a particular point to review those logs after the holidays.
   Log review can be automated but should not be reduced to a formality.  Staff with familiarity with what is normal should be reviewing daily log reports and periodically
   examining the raw logs themselves.

3. Consider internal alerting systems such as Microsolved’s “Honeypoint” solution.  They can act as tripwires in your network, alerting you to the presence of an intruder.
   See: http://www.microsolved.com/honeypoint

Bill Hagestad added:

To prevent surprise cyber attacks the number one focus should be proactive cyber threat intelligence specifically related to your company based upon the following Essential Elements of Information (EEI):

– What are your priorities for intelligence?
– Competitor’s needs/focuses?
– External vendors interests on behalf of competitor?
– Foreign economic interests
– Commercial cyber espionage
– Foreign cyber espionage?
– Potential insider threats?

Once you have prioritized what you consider the information security threats are to your organization MicroSolved can help develop a information a security/assurance strategy.
First step determine a quick list of cyber intelligence targeting baed upon the EEI above;
Second – from the priorities determine your internal High Value Targets that the prioritized list of adversaries might focus on;
Third – install or fine tune your HoneyPoint Security Server to capture attacker and threat vector information; and,
Fourth – focus holiday staffing levels and efforts to mitigate list of potential cyber threats based upon both the EEI and steps 1 -3 above.

John Davis stated:

One of the things to pay particular attention to during vacation season is the security of returning portable devices. Employees will probably be traveling all over the place on their vacations, include foreign countries. And while traveling, people like to let their hair down and take it easy. They also like to keep abreast of their emails or surf the Internet looking for restaurants and places of interest.
Hotel networks and public hot spots are usually open networks and liable to sniffing by enterprising cyber criminals. Because of this, it is relatively easy for these attackers to implant Malware on laptops or other portable devices used by traveling employees. And, as we know, lots of enterprises these days have bring your own device policies in place or tolerate the casual use of company laptops for non-business purposes. To protect the network from this scenario, run anti-virus and other Malware detecting software on these devices, and/or boot them up in a stand alone test environment and look for problems before allowing them onto the production network.

There’s a LOT of good advice here. Hopefully, some of it helps you. Until next time, thanks for reading and have a safe holiday!

Ask the Experts: Travel Abroad with Electronics

Posted on by
6

This time around, a reader wrote in with a very common question:

Q: “A member of my management team is about to go on a business trip to a country with known cyber-spying capabilities. She wants to take her phone, tablet and laptop so she can be productive on the road. What can I do to make this safer for her and our organization without restricting her work capability on the road in an unreasonable manner?”

Adam Hostetler opened with: 

The standard here is don’t bring anything electronic, if you can help it. In most cases, that’s not probable so don’t bring your normal personal phones or laptops, no smartphone at all is advisable. Bring loaner devices that have only exactly what they need and can be burned when they get back. Only connect through a VPN, and have that account monitored on the other end. Don’t leave phone or laptop in a hotel room, even in the safe, and don’t talk business there either.

Jim Klun added:

There is likely no way to do this without restricting – or at least significantly changing – the way she works. 

It has to be assumed that any information on her personal devices will be compromised. 
It also can be assumed that any information flowing between her devices and the outside world will be compromised. 

I would recommend two things:

1. Take only what you can afford to lose. Communicate only what you can afford to lose. 

        So – take a small number of devices (e.g. phone, laptop) minimally configured with only that information absolutely required for this trip. 
        Better to have corporate staff respond to email requests from her rather than to allow access to critical corporate resources from suspect location. 
        If internal connectivity to corporate resources must be allowed ( e.g VPN) it should be ideally require 2-factor auth of some sort, use strong encryption, and grant access only to a limited subset of resources. 
        All credentials can be assumed to be lost – hence the utility of two-factor.  All of the employees credentials should be changed on return. 

        All devices brought back should be assumed to be compromised and will need complete re-imaging. 
                

2.  Consider creating “go-kits” and well-defined repeatable processes for employees who travel to such locations. 

     A special set of devices ( laptop, phone, etc) that are minimally configured and can be wiped on return.  No personally owned devices should be allowed. 
     Connectivity for those devices – if absolutely needed – that allows access only to a tightly restricted and monitored subset of internal corporate resources. 
     Most importantly – training for employees who make these trips.  The employee must understand the special risks being incurred and be aware of their responsibility to protect the company and the companies existing customers.   
      As above – all of the employees credentials should be changed on return.

Bill Hagestad summed it up with this: 

This one is near and dear to my heart…I call these rules of counter cyber espionage the  李侃如的中國旅遊規則 (Lieberthal’s China Travel Rules)

Cellphone and laptop @ home brings “loaner” devices, erased before he leaves home country & wiped clean immediately upon returns;

In China, disable Bluetooth & Wi-Fi, phone never out of his sight;

In meetings, not only turn off his phone but also remove battery, microphone could be turned on remotely;

Connect to the Internet only via encrypted, password-protected channel, copies & pastes his password from a USB thumb drive;

Never type in a password directly, “the Chinese are very good at installing key-logging software on your laptop.”

The article can be found @ http://www.nytimes.com/2012/02/11/technology/electronic-security-a-worry-in-an-age-of-digital-espionage.html?pagewanted=all

Brent Huston closed with:

Any electronic items they do take on the road with them should be current on patches, AV signatures and detection capabilities. All data, drives, systems, etc. should be strongly encrypted when possible to do so (Pay special attention to export restrictions on crypto depending on where they are going.) Also, turn and burn EVERYTHING when they come back. Treat all media and data obtained during the travel as suspicious or malicious in nature. Trojans of data and documents are common (and usually they scan as clean with common tools). This is especially true for high value targets and critical infrastructure clients. Trust us! Safe travels! 

李侃如的中國旅遊規則

(Lieberthal’s China Travel Rules)


ØCellphone and laptop @ home brings “loaner” devices, erased before he leaves home country & wiped clean immediately upon returns;
ØIn China, disable Bluetooth & Wi-Fi, phone never out of his sight;
ØIn meetings, not only turn off his phone but also remove battery, microphone could be turned on remotely;
ØConnect to the Internet only via encrypted, password-protected channel, copies & pastes his password from a USB thumb drive;
ØNever types in a password directly, “the Chinese are very good at installing key-logging software on your laptop.”

Ask The Security Experts: Public Facing Workstations

Posted on by
3

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.

Ask The Experts: Malware Infection Mitigation

Posted on by
1

This time, we have a question from a reader:

Dear Experts, I’ve been fighting with my help desk team about the proper response to a malware infection. Once we know a workstation or server has been infected, what should we do to make sure that machine is clean before we put it back in service? We have heard a variety of stories about cleanup versus rebuild. What is the MSI security expert’s take on the proper response to malware infection?

John Davis replied:

It would be nice to be able to eliminate Malware without having to totally rebuild your computer. I wish I had some good news for folks on that score. But unfortunately, the only way to be sure that a malware infection has been totally eliminated is to do just that: rebuild your computer completely from reliable backups. This illustrates the importance of making frequent backups and storing those backups securely!

Adam Hostetler also added:

The only proper response is complete wipe and reinstall. It’s impossible to say it’s clean after it has a known infection, one part might be gone but the malware may have installed or downloaded other components that weren’t detected. I recommend having a good image to use on workstations, and store as little data on them as possible, so a quick turn around is likely. It’s also a good idea to implement strong egress controls on your firewalls and monitor them. This helps in preventing malware from doing damage, and aids in finding infections. 

Got a question for the Experts? Get in touch on Twitter (@lbhuston or @microsolved) or via the comments. Thanks for reading!

PS – Chris Jager (@ChrisJager) points out on Twitter: Also to consider: Closing vuln that allowed the malware onto the host & refreshing backups & build docs w/said updates.

Thanks Chris! We just ASSUMED (yeah, we know…) that was already in scope, but good to mention that it should be pointed out. Clearly, making sure the bad guys lose their foothold from being re-exploited is CRITICAL.

Ask The Experts: Getting Started with Web App Security

Posted on by
Reply

Question from a  reader: What should I be paying attention to the most with regards to web applications? My organization has a number of Internet facing web applications, but I don’t even know where to start to understand what the risks and exposures might be.

Adam Hostetler responds:

The first thing I would do is to identify what the applications are. Are they in house developed applications, or are they something like WordPress or another framework? What kind of information do they store (email addresses, PII, etc)? If they are in house or vendor applications, have they been assessed before? With a little knowledge of the applications, you can start building an understanding of what the risks might be. A great resource for web application risks is the OWASP project. https://www.owasp.org

Phil Grimes adds:

When it comes to web applications, I always promote a philosophy that I was raised on and continue to pound into my kid’s heads today: Trust but verify. When an organization launches an internet facing application there is an immediate loss of control on some level. The organization doesn’t know that the users accessing the application are who they say they are, or that their intentions are “normal”. Sure, most people who encounter the app will either use it as intended or if they access the app inadvertently, they may just mosey on about their merry way. But when a user starts poking around the application, we have to rely on the development team to have secured the application. Making sure identity management is handled properly will help us ensure our users are who they say they are, and validating all data that a user might pass to the application becomes an integral part of security to ensure possible attacks are recognized and thwarted.

John Davis comments:

I would say that the most important thing is to ensure that your Internet facing web applications are coded securely. For some time now, exploiting coding weaknesses in web applications has been one of the leading attack vectors exploited by cyber criminals to compromise computer networks. For example, poor coding can allow attackers to perform code injection and cross site scripting attacks against your applications. The Open Web Application Security Project (OWASP), which is accessible on the Internet, is a good place to learn more about secure web application coding techniques. Their website contains lots of free tools and information that will help your organization in this process. There are also professional information security organizations (such as MicroSolved) that can also provide your organization with comprehensive application security assessments.

As always, thanks for reading and let us know if you have questions for the experts.

Ask The Security Experts: Mobile Policy

Posted on by
1

This time around, the experts offer insights on this question:

Q: “Dear Experts, what are the key things I need to keep in mind when I write my company’s mobile security policy?” — MK

John Davis starts us off with:

I would say the most important thing is to actually write your own policy; don’t just copy a generic mobile security policy from the Internet and adopt it as your own. For a mobile security policy to be effective, it needs to be tailored to meet your organizations particular information security requirements and also needs to reflect the reality of mobile device use at your organization. It won’t do you much good to forbid using mobile devices for business purposes if you have no mechanisms in place to prevent or detect such uses. Effective information security policy, like effective statute law, is both practical and enforceable.

Adam Hostetler added:

Keep in mind what kind of current security policies you have, and try to apply that to the mobile sphere. Users need to understand that they are connecting an additional computer to the network, and not just a “phone”. Keep in mind also what kind of deployment you are using. Is it bring your own device, or is it company provided? There will be different policies and procedures for each method and possible user backlash depending on how you are doing this.

As always, thanks to the experts for weighing in, and to the readers for the questions. Keep them coming!