Skip to main content

Human Factor in Protecting Information Systems

Many a times we talk about vulnerabilities, exploitations and other specific issues that cause an would be attacker to be successful in breaking into systems. But looking at the different varieties of attacks and other specific payloads used for the break in at the end of the day, it has always been a brute force or a social engineering attack that benefits the maximum, at least from the attackers point of view.
All the recent XSS attacks like the one against Apache, JIRA are all because of the fundamental weakness - Humans - As long as we have people handling certain activities and ways of doing things, these kind of  breaks would continue and go on for a long time. Many say two factor solves the issue, but have in my experience found so many two factor fobs having their  primary username password scribbled or hanging on the fob. How useful that is.

The purpose of the two factor can be easily defeated and again it is the indefatigable (wow where does that word come from - may be it exists) user.  Many a times, it is desirable for the builds to be automated with a set of scripts to ensure there is consistency and human errors do not creep in. The other important aspect to be taught to the administrators is use a different set of passwords and usernames for your application (web app or any other app) and the operating system. We have also seen many a times, that a
easily crackable user name and password combination exists in the web application and has a corresponding account in the operating system with sometime sudo permissions. The simple idea is to separate the OS from the overlying application layer. Segregation of users may not be possible but at least an option to segregate the different components with its own set of passwords may mitigate the issue to a certain extent. A simple paradigm would be to ensure that we have consistent roll outs with minimal human interventions, though this may not be possible when it comes to a small set up where the cost of automation is not warranted. Even in such instances, it is always recommended to go in for a standard build. Build a maker checker functionality, the human fallibility when it comes to checking your own work is phenomenal. It is as good as absurd and always would be gaping holes when it comes to checking what you have done. Self audit is fine, but humans have a tendency to go about and ignoring something, because of the fact, that they are confident about what they did and the fact that it was completed by them, gives them that false sense of security. Always have another person to run through the builds, use a tool to scan and provide you with basic inputs. A tool is only as good as how well it is configured. Ensure that you use the tool properly. And presto many a problem may vanish.
Labels:

Comments

Post a Comment

Popular posts from this blog

The Convergence of Epistemologies: Mapping Quantum Physics to Ancient Indian Thought

The "Retrofitting" Fallacy A common critique from Western academia is that modern Indians suffer from "post-diction"—waiting for quantum physicists to make a discovery and then conveniently shoehorning it into a vague verse from the Upanishads . This critique relies on a fundamental misunderstanding of both language and methodology. The ancient seers ( Rishis ) were not writing religious poetry or mystical metaphors; they were writing cognitive science, cosmology, and metaphysics in a highly technical, high-context language (Sanskrit). When 19th-century colonial translators—who operated strictly on a Newtonian, binary, mechanical worldview—encountered these texts, they did not have the scientific vocabulary to comprehend them. They translated precise technical terms into crude religious dogma (e.g., Maya into "illusion"). Today, we are not "retrofitting" the old books to match new physics. We are finally acquiring the scientific vocabulary requi...
Post a Comment
Read more

The CyberRange Exercise - What it entails and Why?

A cyber range exercise is a simulated cyberattack that is used to train cybersecurity professionals. Cyber range exercises can be used to train a variety of skills, including penetration testing, incident response, and threat hunting. Cyber range exercises can be customized to fit the needs of the organization or team. For example, an organization that is concerned about ransomware attacks could create a cyber range exercise that simulates a ransomware attack. The size of the team that participates in a cyber range exercise can vary. Some cyber range exercises are designed for individuals, while others are designed for teams of up to 100 people. The roles that the team members play will also vary depending on the exercise. Some common roles that team members play in cyber range exercises include: Attacker: The attacker is responsible for trying to exploit vulnerabilities in the system. Defender: The defender is responsible for defending the system from the attacker. Observer:...
Post a Comment
Read more
CYBERRANGES - The Playground to hone your Information Security Skills   Cyber ranges are simulated environments designed to train individuals and teams on how to detect, prevent, and respond to cyber attacks. They provide a safe and controlled environment where security professionals can test their skills and practice real-world scenarios without risking the security of actual systems and data. Here are some reasons why cyber ranges are a great tool for training: Realistic Scenarios: Cyber ranges are designed to simulate real-world scenarios, so security professionals can practice dealing with various types of attacks in a controlled environment. This helps them gain experience and develop the necessary skills to handle real incidents. Safe Environment: Cyber ranges provide a safe environment for security professionals to experiment with different tools and techniques without risking the security of actual systems and data. Collaboration: Cyber ranges also promote collaboration and...
Post a Comment
Read more