-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_C…
[1] https://lists.fedoraproject.org/mailman/listinfo/security
[2] https://fedorahosted.org/secure-coding/
- -- Eric
- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project - Red Hat
sparks(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3BEmAAoJEB/kgVGp2CYvcJ8L/RE75c9Ww/B8cNe2pwTBD9yv
6FGfK50QFMlRC6voq2Fd5RZb8Hf+PKoxw4+ewbUYdnN8t0n+DaEvPxP69hJtgJ5N
N1736+aD6OiiArKrdfBO4A9syXfMEmOPsqmye7WuXrripJc8asxu8jrh1DgEjwXk
rFrI2pau3upnzkwRHDTRnMPZ925g3BE7SnHa+UD2KZQ3B29Qos3FHmaX5Kn3LXf+
3h+zNnIVkClGr1HK56QVxgsjNWApIH/HsCspxwOpr3ULKRvWD8FJjVxEyp1EDCrc
Fw0C6Di7hbzM5VNVpg4CUpquoG9QCnbNniF+IEIzcBWHr1MEKSmq64xFhfXFS0Zx
w0wWmDQHmwBYxp+v9FKzuGbyb5YQAkZm7z/wRu1dfL6d39LBzG5y48zIEgmIUL6t
eZX5o+lAc/3/W9sKfBbB0dmEq9m02jTIER96aD8iXNEyU8B6Yr34fnWyTiJ6BmYA
Z0/ZPvq+vRJGl/F+pZkhekm8yYxA+4R8AdUnDwTt1A==
=AU1I
-----END PGP SIGNATURE-----
Hi security team. I'm working on
https://fedoraproject.org/wiki/Changes/VisibleCloud
which proposes promoting the Fedora Cloud image on basically equal footing
with the desktop download. Daniel Berrange gave the useful feedback that
while installation-based distribution allows one to install updates at build
time, image-based distribution means that the image must be booted to apply
updates, giving a window of insecurity. (Unless careful measures are taken.)
When there was a security issue with the previous Fedora image, we did do a
fire-drill with an adhoc respin and pushed new images. Dan suggests that we
develop (in coordination with the qa and release engineering teams) a
security policy for updates to the cloud image.
Is this of interest?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
Ruxcon 2013 Final Call For Papers
Melbourne, Australia, October 26th-27th
CQ Function Centre
http://www.ruxcon.org.au/call-for-papers/
The Ruxcon team is pleased to announce the final call for papers for Ruxcon.
This year the conference will take place over the weekend of the 26th and 27th
of October at the CQ Function Centre, Melbourne, Australia.
The deadline for submissions is the 31st of August.
.[x]. About Ruxcon .[x].
Ruxcon is ia premier technical computer security conference in the Australia.
The conference aims to bring together the individual talents of the best and
brightest security folk in the region, through live presentations, activities
and demonstrations.
The conference is held over two days in a relaxed atmosphere, allowing
attendees to enjoy themselves whilst networking within the community and
expanding their knowledge of security.
For more information, please visit the http://www.ruxcon.org.au
.[x]. Important Dates .[x].
August 31 - Call For Presentations Close
October 26-27 - Ruxcon Conference
.[x]. Topic Scope .[x].
o Topics of interest include, but are not limited to:
o Mobile Device Security
o Virtualization, Hypervisor, and Cloud Security
o Malware Analysis
o Reverse Engineering
o Exploitation Techniques
o Rootkit Development
o Code Analysis
o Forensics and Anti-Forensics
o Embedded Device Security
o Web Application Security
o Network Traffic Analysis
o Wireless Network Security
o Cryptography and Cryptanalysis
o Social Engineering
o Law Enforcement Activities
o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)
.[x]. Submission Guidelines .[x].
In order for us to process your submission we require the following information:
1. Presentation title
2. Detailed summary of your presentation material
3. Name/Nickname
4. Mobile phone number
5. Brief personal biography
6. Description of any demonstrations involved in the presentation
7. Information on where the presentation material has or will be presented
before Ruxcon
* As a general guideline, Ruxcon presentations are between 45 and 60 minutes,
including question time.
If you have any enquiries about submissions, or would like to make a
submission, please send an email to presentations(a)ruxcon.org.au
The deadline for submissions is the 31st of August.
.[x]. Contact .[x].
o Email: presentations(a)ruxcon.org.au
o Twitter: @ruxcon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I thought this article was an interesting read. An interesting attack vector that caught this company off guard.
http://labs.spotify.com/2013/06/18/creative-usernames/
- -- Eric
- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project - Red Hat
sparks(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3JvkAAoJEB/kgVGp2CYvoPwL/R53Rwx7Th8zd6NPd1UxH4My
ZkjPpwd7VxXBpdtX8nG5g4RNXApwv61jeeSuhB4uTF2BxNMdSAGMo6o/i+eaJfMP
Sw6PbzADJuFvY+n9YuJ0dPPFo0gYsLqdEYpk9GdRdF3rOyhO4+I78z+AfLLGxlvQ
N3DmBFLwDgb/+N7prZwTQvrwPcXai7emaeiFmckXXc6Ps5IOTJWqAJOi2XJSnrkL
Lwa6mGLOHhKmCQc0nk2VjBfpWIAac4HEmZBgcCcFAFn1oRqgZgZNo8zNUbcOpp/6
1VPp4QFJGSpo4KEDw0h2bwPretj7pJ46C3MblwQP4j7TqV9Xj2blCfnj6034hbZj
QRwTCGa92abciC7jXbei4TClrdlLjOD1HlmDZ3MwMzJbmogowcTh9z82/9gawm0U
9BmmU8Wb+M1ThAAqN3DK1TvzCG8y3Khh+9jZXp6QYggzN043gwEmCxv+24Wex7Pm
7vlM+qB5rFkw+E1Ew+vuMOflBdeoLI4E7g1hXOivMg==
=tEIp
-----END PGP SIGNATURE-----
