Author: DanielOwen

A career in Information Security will lead to failures and setbacks. If you are not prepared for that reality please look at a different profession. Unfortunately, setbacks will be true of most professions so maybe stick around until the end of this short piece.

There will be days where you fail to demonstrate risk in a meaningful way. Those days will feel like bashing yourself in the head with the metaphorical hammer because “the risk is so obvious how anyone can not see this?” But I already gave you a potential answer. You failed to demonstrate risk in a meaningful way.

When this happens you have a few options. You can walk away. This may be the correct solution. The organization may actually understand the risk and simple accept that risk. If you have not read my article on risk acceptance, do so.

It’s also possible you are pointing out a risk that you do not understand and truly is below the threshold of importance. These are okay to walk away from until the underlying risk changes or the acceptable risk threshold changes.

But, you say, this is important and the business does not understand. Now we are back to our previous explanation. You failed to make the risk understood. When that happens it is your job, as a professional, to go back to your toolbox to look for a new hammer and bash your own head again if need be. Then go through the whole process again until there is understanding that leads to remediation, acceptance, or a new understanding on your part that leads you to walk away. Any of these will likely leave you with a headache and may leave you with scars but you will also come away wiser as to how to build and when to leave the lumber untouched.

In an effort not to allow the metaphor get in the way of the point, I should clarify that when you walk away you should not immediately charge back with a new argument (hammer). That will simply lead to colleagues dismissing you sooner. Let time pass. Pick your opening. That’s all part of picking the right hammer.

I’m going to go buy stock in Metaphorical Hammers Inc. I see no end to their profitability. Sometimes, repeating yourself is the only way forward and we are paid to help our companies move forward.

https://www.linkedin.com/pulse/beat-your-head-new-hammer-daniel-owen/

Far too frequently the term DMZ is being used for something that is not a DMZ. This creates confusion and weakens security in organizations trying to do just the opposite.

I don’t entirely understand this misuse of the term beyond decades of watering down of the meaning. A network DMZ comes out of the military jargon Demilitarized Zone which is a fair place to start when trying to understand the traditional purpose.

A network DMZ quite simply is an untrusted network that holds company assets. These assets should be hardened hosts (bastion hosts) that are expendable when they are breached and hold no data of more importance than can afford to be lost.

The classic DMZ sits outside the network firewall directly on the Internet. A more common modern approach is a separate network that allows inbound connections from untrusted sources but does not have any access to the more trusted internal network.

In some cases, we also use internal DMZs. These internal networks hold all the resources needed for a specific application and may allow permissive inbound access but no access to other company resources from within the DMZ. An example of this would be an outdated application that is needed by the business for historical records but can no longer be sufficiently protected to allow it to be on the same network as other systems. Another example might be an untrusted applications, such as an HVAC system, that is used for services independent of the rest of the business.

The important issue in all of these cases is that the DMZ has no access into a more trusted network such as the generic server LAN or workstations LANs. What I hear people talk about across every type of business and industry is a DMZ that only allows access to X application in the LAN. A common example might be allowing access to an internal SQL server that holds both public data and proprietary data. The issue is that once that SQL server is accessible from the DMZ it is no longer a protected system and becomes the doorway between the DMZ and more protected networks.

The only traffic that should enter from a DMZ is traffic that would also be allowed from an untrusted network such as the Internet. This leaves a great deal of flexibility depending on the security posture of the company. Not that I would endorse this, but if your company allows direct inbound access to SMB shares on the LAN from the Internet there is no harm in a DMZ accessing the same. On the other hand, if the mere idea of exposing SMB to the Internet worries you, and it should, then allowing the same access from a DMZ should also worry you.

There may be times where the risk of allowing access from a less trusted network segment is acceptable, especially for internal segmentation. Please don’t call the segment a DMZ. It’s a segmented network or an application network. Network segmentation is a good thing. Using terminology correctly will help us all understand the conversation without having to explain a lot of exceptions of why what we say is not actually what we mean to say.

https://www.linkedin.com/pulse/doesnt-mean-what-you-think-does-part-2-dmz-daniel-owen/

Note: To some extent, this is a counterpoint to another article of mine titled “Security – Quit saying no… or how to say yes for success”

In IT and IT security you will almost certainly find your fair share of bad ideas. As humans, we tend to follow two paths when presented with such a challenge. Either dismiss the idea outright or go along to get along. As an expert, it is your responsibility to express your opinion, backed by facts and experience, when you see an idea that may harm the company.

First of all I want to be clear, in this article I am talking specifically about projects that may materially harm the company and not projects that are simply suboptimal. Suboptimal projects should always be negotiated to attempt to improve them but save your rare no for the ones that are going to cause significant business damage.

I should also be clear that unless your title happens to be CEO or Owner your no may not stop the project. This is also acceptable as long as you have explained your concerns clearly. You may not have all the details and as an IT professional it’s not your role to decide what risks the company can take on. It is absolutely your job to make sure that the company knows about risks you have identified.

Having gotten all the preliminaries out of the way the thesis of this argument is actually pretty simple.

In your career, there are projects that you will be made aware of that are simply ill conceived and proposed by those in power out of a lack of understanding or to push a personal agenda. If you have built up a reputation for fairness and thoughtfulness, in most cases you should be able to inform or negotiate to an acceptable solution but, there will be some occasions where the person pushing the initiative will not be persuaded or accept compromise.

In the case where there is no compromise to be had, you must first consider who is pushing the initiative and the criticality of the issue you identified. If the issue is minor to moderate and the person pushing the initiative is significantly more powerful than you are you may want to walk away and simply ask the sponsor to sign off on accepting the risk. There is never a good time to die on your own sword for an unimportant battle.

On the other hand, if this is a significant risk it is your responsibility to inform and mitigate the risk to the best of your ability. If you are still not gaining traction, consider that there may be forces at hand that you are not aware of. If after contemplation and discussing your concerns with the sponsor you still feel this is a catastrophic mistake, you have two options. Continue fighting or walk away. I will caution you that in most circumstances walking away is your best career option.

Fighting on against an entrenched opponent with more power has a strong potential to have negative outcomes for you personally. It will drain political capital that you have worked to build. Depending on how nasty the fight gets, it may make the environment so uncomfortable that you are no longer welcome even if you “win”. You have to decide whether these risks are worth the fight.

In short, as a professional, it will, on occasion, be your job to say no but, those occasions should be few and far between outnumbered by negotiated agreement but a huge ratio. When you decide to give a hard no and dig in you should be aware that the person you are digging in against is only fighting back because they equally believe in their position and they think they have the facts or the political power on their side to prevail. Saying no in this position is inherently risky to your career with the company so ask yourself the question is this hill worth the personal and collateral damage the fight will cause? More succinctly, would I be willing to walk away from my current position rather than see this implemented? If you answer yes then you should fight and accept the outcomes positive and negative. If you answer no, then go back up several paragraphs and see my notes about negotiation and asking for risk sign off then move on with your career.

There are times when saying no is the only option the meets you fiduciary duty but if you find that you are saying no continually something has gone wrong.

In IT security we are paid to worry about risk and stop it where we can. For this reason many IT Security groups have a reputation for being “the department of no” where projects go to die. I’ve been part of the department of no and teams would try to hide projects from us and the same teams would drop hints about what others were doing to keep us busy or sabotage other teams who were working on competing projects. This is not healthy for the organization nor the effort to improve security.

You might say “but they are idiots and want to …” “and that’s going to create all sorts of downstream security headaches.” To begin with, unless you are working in the world’s worst company that really does hire and retains idiots, in which case you may want to take a long look in the mirror, lets first off assume that the teams you work with have reasons for their actions. Secondly those reasons may very well be bad for security.

Your first goal when working with other teams is to get inserted into the process as early as possible. It will be much easier to re-design a poor project if you know about it before code has been written, contracts have been signed, or equipment has been procured. If you find that you consistently find out about projects right before, or worse yet after, deployment then step one should be to work on the culture to make sure you are included in new projects. To do this you can’t say no to everything. Put simply, partners are included; obstructions are avoided.

Once you find out about a project, whether it be in early planning or six months after deployment, your first goal should be to understand what the business owner is trying to accomplish. Once you understand this you can begin to try to understand the architectural choices. Once you understand the design it is time to begin the process of identifying risk. When risks are identified it is important that you go back to the business owner and explain the inherent risks and propose alternatives or failing that work with the business owner to identify more acceptable solutions.

Ideally, you should never go to a business owner with a newly identified problem and no suggestions for resolution or at least mitigation. That is a symptom of “no” thinking. If you can’t discover a mitigation yourself you should, at a minimum, take an approach of suggesting collaboration to find a solution. There are two reasons for this. One, it’s simply less combative and more likely to work. Secondly, left on their own, people who do not necessarily understand all the nuance of the issue you have identified may very well create a solution that meets the minimum requirements you have laid out only while making the overall architecture worse.

In security we far too frequently silo ourselves in out specialist cocoons and don’t communicate enough. I’m certainly guilty of this myself. But, we must exert effort every day to get out of this cocoon to understand the business and make sure we are building toward a better company. Saying no to every risk that comes along without offering constructive alternatives will assure that you are locked tight in your cocoon and everyone makes an effort to keep you there, ineffective and isolated.

https://www.linkedin.com/pulse/security-quit-saying-how-say-yes-success-daniel-owen

In IT the customer is not always right but they had a reason for whatever “crazy” new request they made. As IT professionals it is our job to understand why the customer (end user, other team, remote facility, or whoever your customer is) made the request and how we can help them meet their goal without wrecking our plans and goals.

If you simply ignore or dismiss the request of your users you are inviting shadow IT. Shadow IT will not be managed or secured but will eventually become critical to some part of the business at which point it will become the responsibility of IT whether there are resources available to manage it or not.

By partnering with your customers to find solutions to their problems you will assure that when new needs or wants come to the table you will have an opportunity to help direct the conversation and pick a solution at the beginning before you get stuck with an unmanaged and unmanageable product at the end.

It’s not unreasonable for those of us in IT be expected to understand the needs of the business and to help grow the business. It’s time that more IT departments come out of the Data Center to sit with the business. If that’s not your desire there are plenty of jobs in IT that don’t require personal skills or judgement. If you are going to be in a business facing, decision making area of IT it’s time to work with the business. That is not an unreasonable request.

https://www.linkedin.com/pulse/customer-always-right-daniel-owen/?

If you spend more than about thirty seconds in the security echo chamber you will hear someone state the oft echoed “security is everyone’s job”. If you spend another sixty seconds you will find someone saying “no, security is the responsibility of the security team.” As is frequently the case in dichotomies, both parties are wrong.

Security is everyone’s job in the same sense that accounting is everyone’s job. We all do our expense reports but, at the end of the day accounting makes sure everything is done correctly. In the same sense, there are some areas of security that everyone has to help and other areas where the professionals must do the work.

The security group should make every effort to stop phishing emails being delivered to end users. An end user that receives an email attempting to steal money from the company should certainly report that email when it makes it through the mail filters. If both act accordingly neither has to be perfect every time. It is only when both sides fail that there is a problem, which leads into defense in depth which is another topic.

Similarly, there is a point of incompetence for both the end user and for IT security and both need to be addressed. I have seen phishing simulations where end users clicked on a link in an email that had a two word body of “Click here.” In a situation like that, users need training but when they fall for the same thing time after time it may require corrective action. Similarly, I have seen a professional services company “migrate” between firewalls and create inbound any/any rules that never existed before. I’ll give you that mistakes happen but, as professionals, we should hold ourselves to higher standards and there should be repercussions for incompetence. In short, everyone fails eventually and the end user can help sometimes but not every time. Everyone doing their part to create defense in depth helps.

What I am trying to point out here is that there are areas that IT cannot stop with technical means. Phishing emails are going to get through. Maybe, we can mitigate some of the adverse conditions but, if the end user clicks every link that is presented one days something bad is going to land. On the other side there are areas that the end user cannot control and should not be expected to even consider. The firewall is a good example here.

There are too many smart people repeating false dichotomies about the responsibility of IT vs. end users when it comes to security. In a sense security is everyone’s job because we can’t do it without every user being vigilant but at the end of the day IT and IT security has to do the heavy lifting, including training the users who we expect to assist us in securing the environment.

Who is responsible for security? Everyone but, with the understanding that IT Security must provide the tools (training) to allow that and even then IT security will need to pick up most of the heavy lifting because everyone else has their own primary responsibility to consider like making sure my reimbursements happen in a timely manner.