The danger of outbound connections + insider threats

[WhiteHat]

I was working over the weekend to have my OrangePi PC (hence forth will be referred to as SBC) that sits in a DMZ on my network serve dynamic content. As I don't own a public ip. I resorted to having pwncat + AWS EC2 instance work for me to get me a http connection as well as reverse shell on my SBC.

And that got me thinking....

Over the years we have seen an increase in the importance of IT security. Its a welcome change from the simple firewall rules and default security settings that were once the standard.

One area which still does not get much importance OR even if it does, is not heard about or discussed much is the threat of outward connections and insider threats.

Run such connections over port 443+https and you have a connection that is usually very difficult to trace.

Exploiting an insider / piggy banking this using a trojan and you can very easily get into  a secure network and then work your way to elevating your privilege's on a host / expanding your footprint to further hosts.

The solution: HTTP inspection/SSL inspection, but it has its limitations and you can run all sorts of tricks to go around this. eg: Don't use SSH, instead run a http server that can accept specific keywords and perform tasks.

I hope to see much more organizations use an inspection solution so that this threat can be mitigated to quite an extent.

An unconventional way to prioritize work

Let me start off by saying "One size does not fit all OR everyone". Rock, Pebbles, Sand theory of Prioritization does work for some, but most people do not have a prioritization method at all and even if they do it may not necessarily work for them.

So, lets try something new!

Disclaimer: I know how to use this well and when not to use this method, it comes naturally and has worked very well for me and can greatly boost your productivity, but don't overdo it. Knowing the limits and pros and cons of every method is a must.

1) Lets say you have 3 types of tasks you need to do daily (ignore Impact for now)

Sr. No Priority    Time_Required(each task) No_of_Tasks

1         High          2 hrs                                        1

2        Medium     1 hr                                          3

3        Low          15 mins                                     6

most folks will pick up the the work considering descending order of Priority (High -> Medium -> Low). The reason is psychological, we tend to give a lot of importance to tasks with higher priority.

But is it the best way to do things?

I usually use a reverse psychology trick to get the brain to work more efficiently. The human brain subconsciously always thinks that more number of tasks done = more productive and less time required to think about what else needs to be done / less stress.

Hence I end up usually reversing the order. (Low -> Medium -> High) . Lets see how it helps

By the end of 3 hrs

following (High -> Medium -> Low) you would have completed only 2, tasks, your brain tells you that you still have 8 tasks to complete.

following (Low -> Medium -> High) you would have completed 7.5 tasks, now your brain tells you that you only have only 2.5 tasks remaining.

Even though the time required to complete the tasks is same regardless of order used, you will feel much more fresh and ready to tackle the remaining tasks.

Now what if I change the equation to say that there is 1 Critical task (the highest priority level) that takes 4 hrs. Would you still follow the same method? 

=> This is where I would not use the above process, most likely the Critical Task will take priority for me after which I will go back to (Low -> Medium -> High).

Again; understand the context and apply this method, as eventually we need to "Use the right tools/processes for the right job".

Quick and Lazy Ubuntu Docker Instance with OpenJDK

Java being my language of choice (even though I also know VB, Python, x86 Assembly, JavaScript), I always need a Docker instance with the latest JDK installed. Helps me also isolate my projects and make it deployable anywhere I need.

Contents of the Docker file to create a "Quick and Lazy Ubuntu Docker Instance with OpenJDK"

#Dockerfile starts here

FROM ubuntu:latest

MAINTAINER "Kedar Koppikar"

RUN apt-get update && apt-get upgrade -y && apt-get install -y default-jdk

#Dockerfile ends here

Practical Leadership: Delegate the right way

Delegation is a important aspect of Leadership, it also has a high chance of failure OR at best is done mediocrely without any innovation.

Some Leaders feel that if you just tell your reportee what to do, that is Delegating. Others feel that Delegating means micromanaging the engagement to death. But Delegating is more of a journey and less of a one time explanation.

The right way to Delegate for a Leader which has had a rather high rate of success is 

1) Check which of your reportees may be interested to get this task (eg: someone who wants in move to a management role in the future)

2) Explain the tasks related to the Delegated activity

3) Get the reportee introduced to the various stakeholders and inform the stakeholders of the delegation.

4) Show them how to do it once/couple of times as needed, yet encourage them to follow their own way / customize as needed.

5) Check in from time to time on Progress / solve any concerns. 

• Don't micromanage
• Frequently of checkin should be low to begin with and should reduce further as delegation activity matures.

6) Don't just give the task, give authority to perform the task.

7) Appreciate the reportee for taking up the task in a wider forum.

Docker Swarm or Kubernetes?

 Lately I have had 2 leader's come to me with this question "Docker Swarm or Kubernetes?". Their teams were divided on what to use and I was being asked what is your preference and why?

Firstly: Its good to know that Docker Swarm is finally getting mindshare.

Second: Competition is always good.

Short Answer : Kubernetes

Long Answer : Use what fits well. 

There is no doubt that Docker Swarm is super easy to setup and use and for a small team that just knows Docker and that wants to do a quick cluster of Docker instances. Also there are great Web UI's like Swarmpit and Portainer available that assist with the same.

But "Out of the box" Kubernetes gives you the above and some more but with has some complexity to it.

Eventually Kubernetes is used mostly with Docker containers so some might say that a comparison of Docker Swarm and Kubernetes is not really ideal. And I agree to some extent, when I look at those as products but when I look at an end to end solution they can be compared this way.

But from my perspective the single biggest factor for me to choose Kubernetes over Docker swarm is not a difference in capabilities , its more to do with trained personnel available to manage them as you will find a lot more engineers who know Kubernetes than Docker swarm.

But the lines are blurring between the capabilities of the two with time and I see that may be soon enough we will see them as strong competitor's to each other.

Practical Leadership: Take calculated risks

"Risk hai to Ishq hai"

How often do you see Manager's who are extremely risk averse.  I have had the chance to encounter many such Managers who were such risk averse that things would stay in status quo for years even though it would impact them and their teams every day.

But risk averse behavior is not just a behavior that is exhibited by individual's, I have seen entire organization's being risk averse. 

The culture of the organization is usually to blame. The reasons almost always were

1) If you get retaliated on for the risk you took that resulted in a failure.

2) Processes and Rules discourage any risk taking capability.

So what is the solution?

What you should do is to inculcate a culture of taking calculated risks and train / hire leader's who can not only take calculated risks but also get their reportees to take such risks.

Taking Risks is not bad till the time every possible problem it can bring in accounted for. Always have a plan in case things don't work out. 

Calculating Risk and taking them is not very difficult to work with if you follow these  simple steps

1) Research well on what you plan to do

2) Identify Stakeholder's and how it will impact them

3) Anticipate Mistakes 

4) Set Checkpoints and Goals to measure your changes the risk brings.

5) Be ready to course correct OR jump to an alternate Plan

6) Don't be afraid to cut your losses and revert from the Change

7) Learn from your successes and your failures

8) Repeat

and

Something that is not given its due importance but should be which is to "Learn from other people's mistakes"

and least I forget

Enjoy the benefits of the Risks you took when things go as planned.

FIN

Practical Leadership - ESI before CSI

ESI = Employee Satisfaction Index = How satisfied your employee is

CSI = Customer Satisfaction Index = How satisfied a customer is with your service / product

I had had the unique chance of working with Engineering as well as Support teams where CSI was fairly low as in the mid 20's or lower 30's. There were real issues that needed to be dealt with like

1) Processes too inefficient or too dependent on a single person / single team.

2) Lack of Product knowledge

3) Lack of support from Account Teams

4) Incorrectly set Customer expectations

5) Too little resources resulting in too much work

etc

but one area that would almost always get overlooked was how satisfied the Employee was.

The aspects that got invariably missed out were

Right fitment of the Role

Availability of the right resources

Right Mentors

Acting on Feedback from the team.

Conflict Management

Basic concerns about compensation and allowances

Quality of work (reducing monotonous work)

Good Leaders

Vision of the product

There were instances where despite a lot of changes teams would not go beyond 40% on the CSI score's consistently till the ESI aspects were taken care of. > 70% CSI was very much achievable in most cases after taking care of the ESI concerns.

Hence low CSI could very well be a symptom but the Root Cause could very well be low ESI. 

Moral of the Story: Fix the right problems to get the right results.