Thank you for watching the second webinar installment: “Control Your SSH..IT”
We hope that you found the presentation educational, and look forward to your feedback and questions.
Thank you for watching the second webinar installment: “Oh SSH..IT, Now What?”
We hope that you found the presentation educational, and look forward to your attendance and participation next week.
Control Your SSH..IT
Thursday October 16th, 2014 | 10am PDT/1pm EDT
First, it takes budget, and these days budget for something ‘soft’ like this can be hard to come by in any organization. Second, it can be hard to measure any return on the investment. This is a problem with security in general, but with an exercise like training an activity like testing the training can be difficult, and it can add to the overall cost. Third, no matter how much training we give people, it always seems like it doesn’t stick. Especially with something like security where we are often asking people to replace what may be perceived as an efficient or simple method of doing something with a more secure practice that could be perceived as a burden.
And, after training managers may have an expectation that the problem is solved, where really it may not be. This leads to the first bit of advice:
Expectation does not replace inspection.
If we do not test for compliance, we can not truly know if we are compliant.
This is a great lesson for managing internal systems. Systems buried deep in our networks, providing critical operations and accessed only by the trusted staff of administrators at an enterprise are often assumed to be secure. The fact is, they are not inherently secure, but need to be secured. What these servers need to be protected against is the possibility of a compromised account, a user or administrator who exceeds his authority, or a disgruntled user who deliberately abuses their privilege to access a system.
In the case of deliberate abuse, well, it is really very hard to stop. After all, someone has to have access to provide for the administration of our servers. And, we expect them to behave professionally and in the best interest of the enterprise.
And, there we go again, expecting something.
For Linux and Unix servers providing critical services it is not enough to expect the best. The use of a privilege management tool that can record the privileged activity is essential, and provides the ability to inspect as well.
There is a growing trend in enterprises, recognizing that administrative access to servers needs to be managed, protected and recorded. BoKS ServerControl provides the ability to manage the who, how and what of Linux and Unix access, combining account management, access control and privilege enforcement and monitoring.
FoxT Access Management & Governance solutions complement your existing technologies by adding granular control and enforcement of authentication and authorization policies for both privileged and end users. www.foxt.com
Thank you for joining us for the first installment of our 3-part webinar series on SSH. Below are your questions answered.
Re: key management. If keys and logging is configured correctly, ssh/pka is multi-factor authentication which is invariably “better” than single factor authentication. It sounds like foxit’s stance is pointed more towards single factor auth to privileged accounts. Is that accurate and, if so, how is that justified?
FoxT absolutely does not recommend passwords, or another single-factor authentication, as the preferred method of authentication. A key aspect that we were attempting to draw out is that in locally configured and controlled SSH deployments, and with many products that offer SSH access control, the decisions on how SSH is controlled are globally applied. FoxT believes, and the BoKS ServerControl product provides, a much more granular solution to SSH access control than what was discussed in the initial presentation, which was intended to draw out the deficiencies in many SSH implementations. Continue reading
I just read a recent article about IAM (Identity Access Management) projects, and the level of complication that can ensue when trying to plan and implement a project of the scale and scope that a comprehensive IAM project entails.
The theme of the article is that AD (Active Directory), in many enterprises, is the identity store of choice; the idea being that if you could align your enterprise to use a single account, there is an economy of scale, reducing the number of places where access and permissions would need to be managed. Continue reading
Controlling what someone can do once they have accessed a Unix or Linux server within your environment is a goal for every systems administrator and security analyst to set their sights on.
System admins have a purpose to allowing other users of the system only limited access; users mess things up, and that know that. It could be anything from a noob (or novice administrator) who oversteps their knowledge, or it could be an application developer running a script with root privileges that does something like ‘rm -rf */*’. No sys admin wants to have to explain how that happened, or clean up the mess. Continue reading
Sponsored reports from analysts have focused on poor key and SSH management practices, a highly speculative assertion that Edward Snowden somehow used keys to gain access to systems (which he denies), and now the US NIST has published a document that, among other things, puts a focus on ‘automated authentication’ used for application-to-application (app2app) or system-to-system/computer-to-computer (c2c) communications.
NIST now recommends that the same level of focus and account management that has been recommended for year for interactive (people) accounts be placed on these automated accounts. Continue reading
In today’s environment of massive data security breaches organizations more than ever need to deploy a defense in depth.
Firewalls no longer are enough to keep hackers out and prevent breaches. Threats can emanate from all directions, and often the first foothold an attacker can get is on a common desktop or laptop of an unsuspecting person who opens an e-mail attachment or visits a malicious website. Defending these systems is hard, but must be attempted. However, in the face of much evidence these systems will remain vulnerable and continue to be the source of many breaches. It is what happens next that must be considered and prepared for.
After the initial successful breach, the goal of an attacker will be to widen their foothold in an organization until they have compromised the valued data, or have control over the valued systems. Attackers spread themselves through additional systems through lateral attacks, jumping from one machine to the next until they can reach their goal. Each step is an opportunity to prevent or detect the attack, or prevent or detect the next attack.
For these reasons layers of security are required to find and prevent each link in the chain of attack. Continue reading
SSH has received attention over the last year, and much of it has been driven by two studies. The Ponemon Institute and Forrester have both published studies that have raised a lot of attention, and questioned the security of SSH deployments, and both focus on the implementation practices and procedures. The ugly truth is that this vital tool is often little considered in the security plans of many enterprises.
The focus of both of these studies is on SSH key management. This can certainly be a very important topic, especially with a standard/default SSH implementation: if you need to use SSH user-keys for authentication it becomes enabled for all accounts that have access to the system. Continue reading