Ready to Start Your Career?

How To Be Security Conscious

james8 's profile image

By: james8

October 19, 2017

With the revelations of the Equifax hack and the fallout of bad security practices elsewhere, it is noteworthy to revisit the topic of what security means to people and organizations. How to think about security is not only essential everywhere but often needs reminding within organizations that take security too lightly.

In an IEEE article on Security and Privacy written by J.A. Whittaker and Richard Ford, the importance of How to Think About Security is clearly laid out with somewhat livid examples to the reader - often making a person think why didn’t I think of that? Thinking about security is not only thinking about what a good guy might do but what a bad guy will do as well (Whittaker, Ford, 2006, p. 68). This is why having a Blue Team and Red Team can make a significant difference within an organization. Organizations of all sizes and types need to change their security posture. In essence, organizations need to have a proactive stance on offensive and defensive security. Again, it’s not just sufficient to have dedicated teams, however. What’s at the heart of many issues involving security is how it is viewed by individuals and those within the organization, and finally how much people know about security. This is what we normally refer to as being security conscious or alternatively having security awareness.

So how do you view security?  What are some things which would lead you to conclude that something is considered secure? Imagine for example if you were to write down things on a piece of paper about what makes a website secure before visiting a website or logging into one. To many people, there would only be a few assumptions, such as seeing the https in the address bar and seeing the green lock symbol. There is so much more to security however than what the average user assumes. So how is security viewed by others within your organization? Is there an importance or does it seem non-existent?

No matter what school of thought you’re from in the security space, there are several things which should be taken away from the hack with Equifax which all of us can learn from or think about more.


1)      Security in our day needs to be relevant and dynamic

This means three things:

A.    Security needs to be built in not just within software but in policies, procedures, and methods on a continual basis.

B.     Security should be more dynamic rather than static.

C.     Your security stance should be current to your changing requirements.

If the Equifax hack can teach us anything, it should make us rethink about our use of PII (Personally Identifiable Information) everywhere. Social security numbers, for example, are a really “out of date” form of identification which should be changed. We can’t blame organizations anywhere with the problem of using social security numbers. The problem with social security stems large and is essentially built into the system, making it hard to fix with just policy changes. It needs to be addressed with a shift in design thinking, government assistance, and organizational-wide commitment.

Since social security numbers are static identifiers, once they are compromised it’s hard to recoup. Another finessing problem is that the grouping of numbers has a distinctive meaning which could be guessed by an attacker. Certain identifiers should, therefore, be dynamic and hard to guess. For organizations safeguarding this type of information, at present, this means having dynamic security measures built in. For example, instead of having a person just logging in using their password - require multiple steps such as two-factor authentication using tokens or answering security questions.

Equifax, unfortunately, seemed to have a major flaw in this regard. In one article, it was noted that a web portal Equifax used for Argentine customers used the word admin for both username and password (Hollister, 2017, para. 2). This is not only a bad form of security, it’s downright irresponsible. How could this have been thought of a being secure? Especially, when in development there is often a rigorous process of testing and validation followed by code review. Did this not take place? If it did, what was left out?

In many high performing organizations, development follows a more Agile process from gathering requirements to delivering on software. Testing is generally important in all cases of development methodologies, but in some instances, a project could be moving too fast with more focus on functionality rather than security. Could this have happened to Equifax and be one of the reasons it failed miserably in Web Application Security? It doesn’t seem so, but it might have been an issue at one point in time or another. Had Equifax provided more dynamic security measures, however, such as using two-factor authentication on web portals linked to important customer information, things might have turned out differently. Therein lies another problem however which is apparent in this whole Equifax story. Why were certain credit disputes stored in plain text rather than encrypted? After being contacted by Krebs about the blatant vulnerability the portal was taken down when 14,000 credit dispute complaints could potentially be read (Hollister, 2017, para. 4). Given the importance of customer data Equifax was responsible for, it highlights an important lesson for all organizations in placing more emphasis on dynamic security measures.


2)      Scrutinize your web habits and important sites you visit regularly

Have you ever thought about your own web habits? If you’re curious try using a software tool to track what sites you visit, when you visit them, and how often. Manic Time, for example, is a good software to use to track your web habits in detail. After scrutinizing your web habits, you may be shocked at what you find. If you visit important sites regularly be sure to check that the links you’ve visited are consistent and are known to be secure. That is, make sure if your visiting it’s not Catch the misspelling with the second one? Many mistakes have been made by individuals scouring the web and clicking on links that look familiar but are actually phishing websites. Ever do that? Say for example you want to go pay your Verizon bill and don’t remember the link. You type in pay Verizon in a search engine such as Yahoo or Google and get multiple links. Which one is right? As one bit of advice, make sure you write down the direct link to an important site you use such as for financial purposes. If it ever changes, verify with the entity if it has changed and what is the new correct address to use. In other words, don’t just rely on the search engines to pick up the right link for you for important sites you use regularly.

Bringing this back to Equifax, we can learn quite a bit here as well. As a matter of fact, after the hacking revelations, Equifax posted the wrong link to their new website which would allow users to check if they were affected (Scribner, 2017, para. 4). Adding to the dilemma, the wrong link was directing users to the fake lookalike site for nearly two weeks (Cameron, 2017, para 2).   Thankfully, the wrong link that was provided was created by a software engineer showing how easy it was in creating a mock phishing website that mimicked Equifax (Larson, 2017, para 8). Still, after this incident, it wasn’t over with Equifax, as code on one of their websites redirected users towards downloading malicious malware (Puzzanghera, Rabb, 2017, para. 1). These two cases after the hack with Equifax seem to reveal a troubling lack of security awareness. Were employees responsible for posting information on the official Equifax Twitter page just not aware of the right link? Did some just google it without checking internally first? Indeed, there should have been more than one person checking the content to verify if the link was correct before posting.


3)      Don’t be afraid to criticize

If you see something that can be done better or is strange don’t be afraid to mention it. Many mistakes have been made within organizations from people having the mindset that someone else will take care of it or being afraid to criticize for fear of being ostracized in some way. While this may sometimes be the case it is not always so. It can be a source of improvement within an organization if criticism is taken openly and is honest. The response from the Equifax debacle seemed slow within the organization based on several incidents, and might have been responded sooner if people had acted accordingly in good faith on reporting something.


4)      Be serious about cybersecurity

Cybersecurity is never going away anytime soon. It will likely remain with all of us forever and will become increasingly important as we rely on more technology in our everyday lives. Organizations, therefore, must take cybersecurity more seriously. Equifax shockingly had more than two months to address the issue to defend personal data and take precautions but it didn’t (Newman, 2017, para. 1). Being serious about cybersecurity means responding to needs in real-time and as soon as possible.

Finally, please share your thoughts on what it means to be security conscious at home or within your organization. Do you think there is enough security awareness going on within your organization?  In the spirit of National Cyber Security Awareness Month, bring that awareness and let others know.


Cameron, D. (2017). Equifax Has Been Sending Consumers to a Fake Phishing Site for Almost Two Weeks. Retrieved from


Hollister, S. (2017). Equifax reportedly used 'admin' as password in Argentina. Retrieved from


Larson, S. (2017). Equifax tweets fake phishing site to concerned customers. Retrieved from


Newman, L. (2017). Equifax Officially Has No Excuse. Retrieved from


Puzzanghera, J., Rabb, L. (2017). Equifax Takes Down Portion of Website Citing ‘Malicious Content’. Retrieved from


Scribner, H. (2017). Equifax has directed victims of hack to a fake website for weeks. Retrieved from

Whittakter, J., Ford, R. (2006). How to Think about Security. IEEE Security & Privacy. 4(2) 68-71. doi: 10.1109/MSP.2006.39

Schedule Demo