A plea to software developers, vendors and support companies
As part of my job I deal with a lot of software vendors, support companies, consultants and the like. Often these organisations/individuals need a firewall, policy or other change to our security provisions in order for their product to work. Time and time again I'm given an imprecise answer, or the individual just doesn't know how their product works, so here's my plea.
Know your supported crypto
This has come up a few times, most recently with an application used to manage cemeteries. There's what looks like a .Net application installed on the end-user workstations that connects to a web service hosted in our datacentre. For good reason, these web servers only allow TLSv1.2 (SSLv3 and TLSv1.0 are broken, PCI DSS also applies on the network in question). My colleague was working with the vendor and found the application would not connect. Her first question, given she knew about the changes was "does your application support TLSv1.2?". They assured her it did.
Turns out their assurance was wrong. The version that was installed did not support TLSv1.2. We proved this after "Wiresharking" on the web server and spending about an hour testing things, but because the vendor didn't know their software the burden of proof laid with us to show they were wrong. That was about 3 person hours wasted due to a vendor's lack of knowledge.
Oddly enough, they installed the latest version and it all worked - no changes to the webserver required.
Know your ports and destinations
The nature of distributed applications mean there's going to be communication between multiple devices, sometimes between the DMZ and the Trusted LAN. There may also be a hosted component, or an offsite resource, that requires interaction over the public Internet. In each case the network traffic will connect to a port at the destination.
Vendors need to know what port is connected to and where the destination is. I've had requests where a vendor has just asked us to allow connections to some resource, no port specified. Sometimes we're just asked to let "everything out" which we also won't do. If you need me to make a firewall change, be specific about it!
"Two way" firewall rules, really?
Sticking with firewall rules for a moment, my team gets a lot of requests to allow traffic "two ways" or "both ways". In the days of stateful firewalls return traffic is already allowed and that's often the reasons suppliers ask - they want the return traffic to come back and ignore the fact the return traffic won't be returning to the same port their application connected to. The source and destination ports are almost always different.
Unless the device that's being connected to is listening, there's no point opening the firewall to allow that traffic. The vendor should be able to justify and demonstrate the need for "two way" traffic on the ports they've specified - if they can't it's likely just a cop out in my experience.
Can you just try this?
Adding to the IE Trusted sites list...firewall changes...more firewall changes - I've seen this often. Don't get me wrong, I'm happy to try things in the name of troubleshooting but if I get the impression you're guessing I will just stop. I'm busy too and don't have time to waste on guessing games. Add to that the vendor's only on site for an agreed amount of time (or billing by the hour, or both) and it's in everyone's best interests that the vendor knows their product and can present the requirements.
Do vendors really want references like "worked with Acme Inc. on a major project. They booked 3 days but it took 7 as they had to guess what was required to make the product work. Great product, poor installation company." ?
For the good of your support company, development house or organisation: bring the right details and have the right conversations early.
Ask your developers
I fully appreciate not every consultant or company writes the software they install, that makes perfect sense. That said, it also makes perfect sense for them to be able to ask the developers the right questions. If I'm looking at your application as "the firewall guy" and asking you "what ports need to be opened, and to where, for this to work?" then the consultant or similar should be able to answer those questions.
If they can't I'd question the validity of the documentation they've been given by the development team. I understand different organisations have different implementations and requirements but the vendor's documentation should allow the consultant to work out what's needed.
Take eVitabu for example. I'm one of its developers and I can tell you with absolute certainty what ports are required to make it work. For the web management component to function, the web server service (NGinx, Apache2 etc.) must be able to receive a connection on TCP 443 (HTTPS). That's necessary for secured communication with the admin interface. As it authenticates against Google, any client contacting it must be able to reach both Google and the eVitabu server on TCP 443. If, for some whacky reason, it was necessary to change the HTTPS port on the eVitabu server, say to TCP 9443, then I could tell you that also. There's a few other requirements, but you get the gist.
Ultimately the developer of a system should know what's required so vendors need to be asking the question.
Draw a diagram
A picture is worth a thousand words apparently, and a diagram can save many hours of painful troubleshooting. Even a hastily drawn sketch is helpful. The diagram doesn't have to be specific to my environment, just close enough.
Conclusion
At the end of the day, both system administrators and developers/vendors/consultants have the same goal: implement a system so the end user can perform their job more effectively. By having all the right information, at the right time, everybody wins as the project is delivered with reduced stress and delay. If we can all speak the same language, and ask the right questions, we can implement better systems - please do your bit :).
Banner image, "comic clouds 1", from OpenClipart.org, by SRD.
Basic diagram icons:
https://openclipart.org/detail/259126/application-server
https://openclipart.org/detail/163741/web-server
https://openclipart.org/detail/172502/user-3
https://openclipart.org/detail/193560/cloud
https://openclipart.org/detail/171430/firewall