I have done some thinking, and I still have questions on how to improve security.
One way is to use STRIDE to id some threats. One has to sometimes say 'what if' and attempt to address them.
Another way is to wait for some interesting topic to arise in the forum or post our own questions.
Another way to improve securiity, a la mode, is to subscribe to intelligence feeds in your tools. So that you address an attack vector once a POC comes up or when somebody else gets hit.
Currently I am digging into SELinux, trying to put the 'targeted' SELinux policy to full use. NSA thought up this protection, and the 'targeted' policy only uses part of SELinux. It should be able to do wonderful things. Just trying to stay ahead of the red team.
Another proven way to improve is to follow a security framework and implement the controls that they say to do. But some of these frameworks are geared towards bigger shops than ours. They show the proper way to do things, which I fully understand and agree, but man power is a problem. Canada has its own Baseline Security for small medium organizations. And Australia has their Essential 8. Both doable. Essential 8 has clearer instructions. Of course there are those internationally recognized frameworks, like CIS Critical Controls, NIST Cybersecurity Framework and ISO 27001.
What else can you think of ?
You already have several of the right building blocks. The main thing I would add is this:
Security improves fastest when you combine threat thinking, hardening, detection, and recovery into a repeatable process.
Frameworks, SELinux, threat intel, and “what if” exercises all help, but they work best when tied to a practical operating model.
What else to add
- Asset inventory and attack surface reduction
You cannot secure what you do not know exists.
At a minimum, keep an accurate list of:
- Servers
- Endpoints
- Network devices
- Internet-exposed services
- Admin accounts
- Critical applications
- Third-party connections
In many smaller environments, simply removing unused software, disabling unused services, closing unnecessary ports, and reducing exposed applications gives immediate security value.
- Privilege control
This is one of the highest-value improvements for most organizations.
Focus on:
- Least privilege
- Separate admin and user accounts
- Restricting local admin rights
- Just-in-time or just-enough administration where feasible
- Strong MFA for admin access, VPN, email, and remote access
If manpower is limited, reducing privilege often gives more benefit than adding another security product.
- Secure configuration baselines
A framework tells you what to do, but configuration baselines help with how to do it consistently.
Examples include:
- CIS Benchmarks
- Vendor hardening guides
- Microsoft security baselines
- Distribution-specific Linux hardening guidance
This fits well with your SELinux work. SELinux can be very strong, but it usually delivers the most value when the underlying service design, file labeling, and least-privilege model are already disciplined.
- Patch and vulnerability management
Threat intel is useful, but many real-world incidents still come from already-known vulnerabilities or weakly managed exposed services.
A practical model is:
- Prioritize internet-facing systems first
- Prioritize actively exploited vulnerabilities next
- Then high-impact internal systems
- Use maintenance windows and rollback plans
I would treat “patch reliability” as just as important as patch speed.
- Logging, monitoring, and alert triage
Prevention alone is not enough.
Even basic centralized logging can help:
- Authentication failures
- Privilege changes
- New service creation
- Policy denials
- Remote access activity
- EDR or antivirus detections
Since you mentioned SELinux, reviewing AVC denials in a structured way can also uncover misconfigurations and attempted abuse, but it takes tuning to avoid noise.
- Backups and recovery testing
This is often undervalued until something goes wrong.
Have:
- Offline or otherwise isolated backups
- Documented restore procedures
- Periodic restore testing
- A list of critical systems and acceptable recovery times
A backup that has not been tested is only a hopeful backup.
- Security awareness tied to your real risks
Generic training has limited value. Targeted training works better.
Examples:
- Phishing-resistant MFA adoption
- How admins handle scripts, attachments, and downloads
- Safe remote support procedures
- Reporting suspicious emails or login prompts
For smaller teams, a few focused habits can matter more than formal annual training.
- Incident response playbooks
You do not need a large enterprise SOC to benefit from this.
Even a small set of written playbooks helps:
- Compromised account
- Suspected ransomware
- Suspicious outbound traffic
- Lost or stolen device
- Business email compromise
This reduces hesitation and confusion during a real event.
- Validation through testing
This is where your STRIDE mindset becomes operational.
Good options include:
- Tabletop exercises
- Purple-team style validation
- Atomic tests for common attacker techniques
- External attack surface reviews
- Configuration drift checks
You do not always need a full red team. Small, controlled validation exercises can still reveal major gaps.
- Application control and execution restrictions
Where practical, controlling what can run is a strong defense.
Examples:
- Application allowlisting
- Script control
- Macro restrictions
- Restricting unsigned or unapproved binaries
This is especially useful against commodity malware and user-driven execution paths.
- Network segmentation
Smaller environments often have flat networks because they are easier to manage, but this increases blast radius.
Even modest segmentation helps:
- Separate user devices from servers
- Separate backups from production
- Restrict admin access paths
- Limit east-west traffic where possible
This improves containment when something does get through.
- Third-party and supply chain review
A lot of risk comes through vendors, remote tools, browser extensions, SaaS platforms, and update channels.
At minimum:
- Review who has access
- Remove old integrations
- Limit permissions for service accounts
- Monitor remote access tools
- Prefer reputable vendors with clear security documentation
A practical priority order for smaller teams
If staffing is the constraint, I would usually prioritize in this order:
- Asset inventory
- MFA everywhere important
- Remove unnecessary admin rights
- Patch internet-facing systems quickly
- Backups with restore testing
- Secure configuration baselines
- Centralized logging for key events
- Basic incident playbooks
- Segmentation and application control where feasible
- Threat modeling and framework mapping to close remaining gaps
On frameworks
Your point is valid: some frameworks are conceptually excellent but operationally heavy.
For smaller organizations, it is often better to:
- Choose one primary framework for structure
- Use one baseline for technical configuration
- Adopt only a small number of measurable controls at a time
A sensible combination could be:
- NIST CSF or CIS Controls for overall structure
- Essential 8 or a national SME baseline for prioritization
- CIS Benchmarks or vendor baselines for implementation details
That usually works better than trying to “fully implement” multiple frameworks at once.
On SELinux specifically
SELinux can absolutely be valuable, but I would be careful not to overestimate it as a standalone answer.
In general, SELinux is strongest when used as:
- A containment layer
- A way to reduce post-compromise freedom
- A control that enforces separation between services and data
It does not replace:
- Patch discipline
- Identity controls
- Good service design
- Monitoring
- Recovery planning
So I would view it as part of a defense-in-depth model, not the center of the whole program.
A useful mindset shift
Instead of asking only, “What control should we add next?”, it often helps to ask:
- What is most exposed?
- What would hurt us most if compromised?
- What common attacker step is still too easy here?
- What can we simplify or remove instead of protect?
- If a control fails, how quickly would we notice?
- If we notice, how quickly could we recover?
That tends to produce very practical improvements.
Bottom line
Beyond threat modeling, threat intel, SELinux, and formal frameworks, the biggest gains usually come from disciplined basics: inventory, privilege reduction, hardening, patching, logging, segmentation, and tested recovery.
That combination is usually more effective than chasing every new attack trend.
