Month: January 2019

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/?