how engineers differentiate themselves

This is a summary of lessons I learned…the hard way. It took me a lot of time to realize what are the types of activities that would allow me to move forward in what I do.

This is what is always known as, the extra mile, the work that an engineer can get involved in, to get more exposure and experience and that automatically translates to getting ahead.

The general aim is developing strong engaging relationship with Engineering to improve product quality and customer deployment experience, that can be achieved through:

1) Developing and delivering training collateral (articles, books, documentations) for Services readiness, the same as rewriting configuration/user guides to run a new/existing technology, It can be just simplifying an Solution/architecture/feature…i.e : basically breaking down something complicated to an easier form. That can be a blog, a LinkedIn article, Tweets, a Reddit Post or a Youtube video…Social Media is your friend here.

2) Becoming a Technology evangelist, participating in EFTs (Early Field Trials), reach out to engineering, ask for Beta versions of the new features/solution, try it in a lab, and give them feedback, no one will every deny you that. The same can happen for a Customer Proof of Concepts (PoC). Suggest a demo to your customer, partner with sales or other groups to showcase new technologies to customers. It will get you far.

3) Supporting the field (users of your technology of interest) by using public/external mailing lists/communities (e.g : cisco-nsp, nanog…etc), internal forums/mailers. Recreate problems they face and hold their hand, the same can be done over IRC Freenode server, #Openstack, #OPNfV…etc

4) Look for opportunities to present a technology at industry conferences, there are plenty of them (NANOG, Apricot, CiscoLive, OSCon, FOSDEM…etc) if you think its not easy, find a meetup (e.g : Opendaylight users in Texas, or Openstack users in Morocco.

5) Write a script to automate a task, Python or Bash scripts. It does not require a lot of software development experience. These types of scripts can do very powerful things and can take you to places you never imagined. From the top of my mind is Devstack, Its a shell script that installs Openstack, allowing you run a Cloud computing platform.

6) Pick an Open source project, install the code, file bugs, write documentation, influence upstream by requesting usability or serviceability tools/knobs…Basically, asking the coding community to make the product easier to use.

7) Contribute code to Open source projects. It is believed that Linux development slowed down, because whenever someone contributes code to Linux, companies chase them, so there is no one left with free time.

What will differentiate one from others will always be the “unsolicited” effort, the effort that no one asked you to do as part of your daily job, but you decided to roll up your sleeves and donate your time. On the process, you can always do things better. If you do not work for a technology producing company, you can do the same with open source projects, providing valuable feedback to the Engineering teams to develop solid Serviceability and usability requirements, or maybe contributing to the code.

Isolating management plane

A large portion of the attacks come-in on the Management plane, and I’ve rarely seen innovations to combat that.

Most boxes are managed through remote HTTP, SSH or Telnet access, the piece of software that allows this interaction to take place is closely and dangerously tied to the rest of the system, leaving most systems vulnerable.

Can we isolate and separate management plane as much as possible, with a stripped-down to the bare-minimum, optimized, hardened kernel, only for management.

A Kernel is basically an operating system, so the idea is to have an operating system inside/next to the resident operating system. A different kernel dedicated only for management. This kernel should not be bloated with services/features that are not needed and commonly vulnerably for exploitation, specially in Infrastructure devices like routers, switches where they are rarely upgraded.

The TCP/IP stack, drivers…etc of this kernel are either re-written or just stripped down to minimum.

The isolated kernel should allow customers to add filters to the way ‘system calls’ are made. The sys-calls should also be exposed to the user, so they can limit these calls only to the IP address/Authentication credentials of the system admin.

The hardened kernel would be able to authenticate/authorize a user coming-in and could potentially do the same for the user going out. That means, a user may get access to this box but it does not mean they can access to other boxes from this one.

It all comes down to making sure the filters in the hardened kernel are done on a system-calls level, not on a local firewall.

The security policy (who can access, what can be accessed) should be pinned down locally but gathered remotely, that means, periodically, the hardened kernel would check with its policy-server for updates, installing new ones immediately, also sending logs of users behavior for analysis. Having the capability to lock-down a system if suspicious user behavior is witnessed. Locking-down the system is affordable in this case, because its a separate management plane, remember 😉 ?

Less than 0.15 $

Minimize the impact of sniffing packets on a laptop’s CPU utilization

1) Get a decent PC/Laptop 🙂

2) Reduce the number of running applications, preferrably a stripped down version of Linux.

3) Go to Capture>Options, In the pop up window configure a filter for the traffic you want to capture (using IP addresses for example).

4) Filter out unnecessary traffic : Like arp, broadcasts, dhcp…etc

5) Select the ring buffer option and increase it.

6) Dont use Wireshark to capture and Analyze in Realtime, In the options window, disable the real time update.

7) In the Options window, disable dns/name resolution.

8) Because Wireshark does things in memory like reassembled packet streams and information from previous packets that may help dissect future packets. You could turn off features like this, or even disable protocols you’re not interested in.

9) Capture into separate files and not just one single big file.

10) Dont just start a SPAN session on a Physical Interface, if possible Pick the source of the monitor session to be the VLAN or Physical port, whichever has less traffic.

11) Dont use wireshark 🙂 use dumpcap.exe on Windows or just go for tcpdump on Linux…i.e : command line tool with no fancy GUI.