I can give you my view as a Mainframe Security Engineer.
For my role in our company is defined as maintaining and managing risk for our platform in addition to providing direction for our ID ADMIN team.
My typical day consistent of vulnerability management, report generation, meetings (my leadership, IRM, IAM and Audit) and training. Being the only CISSP on our team as well as the team lead it falls to me to train others on my team as well as training to other engineers (not only security but our OS, Network and tower engineers)
I typically start by pulling all the latest vulnerability reports as well as IBM Alerts specific to mainframe. these are reviewed, logged, tracked until resolution. Dashboard are prepared for leadership as well.
Other aspects include scheduling of A&P test for our platform. While A&P test typically go in-eventful one item recognized for us is we have no down time. Day is online processing and night is batch processing. both of which run the company. an outage due to a scan is not acceptable so they are planned for least impact times and systems
Project work is another area where IRM/IAM are making many changes and as the Security Engineer for our platform it falls to us to implement these items correctly.
Training is usually handle via working sessions. we identify an area we need work on then have a daily working session on it where we present the issue, work on how to solve it and then have one or more of our team implement it. we use these as training because most my team are not engineers, they are learning. so they are being taught engineering principles in these sessions
Other training consist of topics like vulnerability management. process management. out reach for our local users groups and attending training like our RACF users group which is our security product..
right now we're working on STIG compliance and developing the skills and tools to provide that compliance.
Hope some of that helps.
I have to say that my day as a Security Engineer is rarely scripted or even the same day to day. I do seem to have more meetings than deemed healthy for sanity, but Project Managers seem to only exist within the context of a meeting or TSP report.
Frankly, my charter is to 1) Serve as the go between (aka Translator) between the IA and IT staffs; 2) Try to solve the technical problems of conducting business and maintaining a reasonable security posture; 3) Talk the PMs off the ceiling whenever they hear that the cheapest solution still has a cost; 4) Ensure that solutions are installed and configured correctly, and stay that way; 5) Explain to engineers and developers why we cannot simply make the firewall any-any, set file permissions 777, use TELNET, RSH, etc..., or run CRON jobs as root. 6) Explain the same ideas to Windows SA's, but gentler so that I don't hurt their feelings. 7) Try to train the security staff to look for a solution, or at least talk to me, before saying No!; 8) Write justifications (ROIs) for my boss for any expenditures for tools; 9) Spend 2-3 times as much money and time as the tool would have cost on labor and time trying to make the "same thing but free" that some budget manager heard about at his off-site team building leadership retreat in the Poconos. 10) Review scan reports, mitigation reports, track action items to completion.
There are a bunch of other things that go into my day. Many of them frustrating. Some of them rewarding. Rarely the same. But, I really like this job for the challenges it gives me every day. I look forward to coming in and trying to solve a problem. I don't mind staying late to make sure something is working as intended. I get to learn new things as well as teach. A good day for me is when I feel like I have accomplished something.
What's involved? Being in a security conscious culture helps or an environment that supports you actively working to increase the security posture.
What do you have access to, and what is just provided? You have access to training material or able to travel to seek out unique training opportunities. Support from senior management and infrastructure teams is another bonus. Visibility into operational procedures is another plus.
What roadblocks that normally exist are no longer present? Visibility into systems or operational procedures may be the largest roadblock that is no longer present in our environment.
How are you growing and developing daily, and longer-term? Working toward helping developers receive additional training quarterly as a mandate and delivering more training in-house. When you can leverage your in-house security engineer talent to deliver training they feel valuable to the organization.
> We have some engineers that are fantastic, but a bit unfocused.
> Looking for feedback on the ideal day for a Sec Engineer.
Have you taken a look at any project management frameworks or tools?
Please don't take any of the following as a negative or a criticism of you; this is not personal -- my replies are process motivated only.
The first thing I would generically suggest is not to be passive/reactive about this, be active. Meaning, if your staff needs focus, if you need to know an ideal day, define it first and then plug the resources into it. Generally, service providers, and you are one, don't have a template day -- that's production speak.
If you've ever read any of the Situational Leadership stuff, recall three basic things about human behavior:
1. All people are motivated.
2. All people are motivated for their own reasons (yes, even slackers are motivated -- see #1).
3. No matter how hard one tries, you can never ultimately motivate people for your OWN reasons.
That, is also, the difference between leadership and management... but I digress.
One way to align a group of high performing but unfocused staff is through team building and accountability.
I have two thoughts for you off hand that are cheap to implement and pay big dividends. As another disclaimer, I understand some of what I'm going to write isn't trivial. Services organizations seem to have more challenges in the areas you mention than production organizations. But if one really looks at the situation without preconceived notions, they can see where parts of frameworks are applicable to their business processes and in turn leverage the cool stuff!
1. One technique you could use is document the work in kanban. It's basically a board which says what work is upcoming, which work is in progress, and which work is completed. Make the board public. Make the team accountable for it -- at all levels. The team should operate as a team and not a hierarchy of pay grades and job titles from a basic service provision perspective.
In kanban, if you have an unfocused employee -- there's no excuse for that anymore; they see the work they need to do (it's publicly posted), their teammates do too, and as staff progresses tasks from in-work to completed, they'll eventually get into the habit going to the upcoming work side of the board and starting a task on their own. They'll do that without team lead intervention and they'll have a lot of pride about it because they are executing autonomously (which is going to free you up for other things too).
An additional benefit is the team sees the work, the entire process is transparent. They will all own it. That's a very powerful motivator.
2. Have you looked at any SCRUM methods?
Implement a morning stand up, no more than 15 minutes and with all team members. During this stand-up, go around the circle and have each team member publicly talk to the team about what they accomplished yesterday, what they plan on doing today, and to escalate any barriers. This is a very powerful tool -- few people want to be a slacker in such an environment where they bring nothing to the stand-up while all their teammates are voicing their accomplishments.
I hope this helps.
Good call. I'd have to second your response:
- Norms & Baselines - What's expected to happen. (What should be done, by whom, how, and when)
- Real-time information - What's actually happening. (What is being done, by whom, how and when)
In my experience, the "tools" are the team that you interact with. If you're conflating "Engineering" with all of the operational tasks like configuration management, auditing, monitoring, and incident response - even longer term analysis, then you're probably not doing the essence of engineering.